From ipfix-bounces@ietf.org Mon Nov 3 07:00:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEF828C21E; Mon, 3 Nov 2008 07:00:04 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4E95C28C1F3; Mon, 3 Nov 2008 07:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103150001.4E95C28C1F3@core3.amsl.com> Date: Mon, 3 Nov 2008 07:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, B. Claise Filename : draft-ietf-ipfix-configuration-model-01.txt Pages : 53 Date : 2008-11-03 This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03065222.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 07:00:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBEF828C21E; Mon, 3 Nov 2008 07:00:04 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4E95C28C1F3; Mon, 3 Nov 2008 07:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103150001.4E95C28C1F3@core3.amsl.com> Date: Mon, 3 Nov 2008 07:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-configuration-model-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, B. Claise Filename : draft-ietf-ipfix-configuration-model-01.txt Pages : 53 Date : 2008-11-03 This document specifies a data model for the configuration of caches, selection processes, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices. The configuration data model is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. A YANG-to-XSD converter is available which allows generating an XML Schema Definition (XSD) of the data model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03065222.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 07:18:27 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF9128C283; Mon, 3 Nov 2008 07:18:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C979D28C283 for ; Mon, 3 Nov 2008 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0sbbD-wrDJ8 for ; Mon, 3 Nov 2008 07:18:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5D4AC28C293 for ; Mon, 3 Nov 2008 07:16:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4850A2C0004E3; Mon, 3 Nov 2008 16:16:45 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Ey1RNM5whf; Mon, 3 Nov 2008 16:16:45 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 15F2F2C000305; Mon, 3 Nov 2008 16:16:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Nov 2008 16:16:32 +0100 Message-ID: <547F018265F92642B577B986577D671C44164A@VENUS.office> In-Reply-To: <490B3993.1040504@net.in.tum.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 Thread-Index: Ack7ej1aACDkSkogQWamOlkOV3OtdgCTIzPA References: <48B7C105.8070708@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C441471@VENUS.office> <490B3993.1040504@net.in.tum.de> From: "Thomas Dietz" To: "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977704070==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============0977704070== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B5_01C93DCF.891C2EE0" This is a multipart message in MIME format. ------=_NextPart_000_00B5_01C93DCF.891C2EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gerhard, Looks like I am editing this draft for such a long time that I don't see = the obvious. You are absolutely right when you say we can join these two = tables. I tried to address all your remaining issues and will submit a new = version in a few minutes. Best Regards, Thomas --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > Sent: Freitag, 31. Oktober 2008 18:00 > To: Thomas Dietz > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 >=20 >=20 > Thomas, >=20 > Thomas Dietz wrote: > > sorry for the late reply. See my comments inline... >=20 > >> Dear all, > >> > >> Please find comments on draft-ietf-ipfix-mib-04 below. > >> > >> Currently, we have ipfixTransportSessionTable which does not = provide > >> any > >> information about the role of the given device within the transport > >> session. We do not know if the device is exporter or collector. > >> > >> On the other hand, you define "directional" tables for the > Templates: > >> ipfixExportedTemplateTable > >> ipfixExportedTemplateDefinitionTable > >> ipfixCollectedTemplateTable > >> ipfixCollectedTemplateDefinitionTable > >> > >> Is there any specific reason? > >> > > > > Yes there is... see below > > > >> There are two alternatives which require fewer tables: > >> 1) One could add an entry about the role of the device to the > >> ipfixTransportSessionTable, for example in form of a field with > values > >> "exporter" and "collector". As the Templates are scoped to a given > >> Transport Session, it is clear which Templates are exported and > which > >> Templates are collected. So we would have only three tables instead > of > >> five: > >> ipfixTransportSessionTable > >> ipfixTemplateTable > >> ipfixTemplateDefinitionTable > >> > > > > That the way we had it before, more or less. >=20 > No, it is not the same as you had before. In the previous version, the > entries in the Transport Session table did not include any information > about at which endpoint of the Transport Session the device is = located. > That's why it could not work. >=20 > I propose to add a column to the Transport Session table that says > "collector endpoint" or "exporter endpoint". >=20 > > The problem is that a device > > potentially can be a collector and an exporter at the same time. We > could > > collect a template with a Observation domain x and a template id y > which is > > not necessarily the same as the template with observation domain x > and > > template id y that we export. The template Ids are only unique at = the > > exporting device. The same is true for the observation domain ids. = So > having > > one table for the templates (ipfixTemplateTable) und in consequence > for the > > template definitions (ipfixTemplateDefinitionTable) does not work. >=20 > There should not be a problem with the additional column I propose > because the Transport Session entry provides the necessary separation > between "exporter" and "collector". >=20 > The ipfixTemplateTable has the following indexes: >=20 > ipfixTransportSessionIndex, > ipfixObservationDomainId >=20 > and the ipfixTemplateDefinitionTable has: >=20 > ipfixTransportSessionIndex, > ipfixObservationDomainId, > ipfixTemplateId >=20 > In both tables, ipfixTransportSessionIndex is index. So, as far as I > understand, this means that there is no problem to use identical = values > for ODID and the same Template ID for different Transport Sessions. >=20 > And there is another disadvantage with your proposal: > It is not possible to know from the Transport Session table if the > device is Exporter or Collector for a given Transport Session. > You must first search the ipfixExportedTemplateTable and the > ipfixCollectedTemplateTable to know that. > If there are no Templates received or exported at all, you will never > know. In this case, the only solution is too match the IP addresses of > the Transport Session table with known IP addresses of the device. I = do > not think that this is a good solution. >=20 > With the proposed column, you get the information directly. >=20 > >> 2) Or, one could split the ipfixTransportSessionTable into: > >> - ipfixOutgoingTransportSessionTable for Transport Sessions where > the > >> given device is exporter. > >> - ipfixIncomingTransportSessionTable for Transport Sessions where > the > >> given device is collector. > >> Again, we only need two tables for the Templates: > >> ipfixTemplateTable > >> ipfixTemplateDefinitionTable > >> > > > > We could split the transport session table into 2 but for the reason > > explained above we still cannot collapse the template and template > > definition table into one. But I don't see the point why to split = the > > transport session table without gaining anything. >=20 > You are right that this does not work. The reason is that we would = need > different sets of indexes for incoming and outgoing Templates in the > ipfixTemplateTable: > - ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for > incoming, and > - ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for > outgoing. >=20 > >> Why is a Transport Session group restricted to the output of a > single > >> cache? > > > > Because that's what a transport session group is for. Export from a > single > > cache to different destinations in different configurations. > > Primary/Secondary for failover, in Parallel, ... >=20 > Ok. >=20 > When I asked the question, I thought that there was a one-to-one > mapping > between an entry in the Export table and an Exporting Process. But = this > is not the case. >=20 > >> Can you explain this example? > >> > >> There are two Metering Processes? And the output is sent to > different > >> primary collectors? And in case of a failure, each collector serves > as > >> backup for the other? > > > > > > Absolutely right. So what do I need to explain??? >=20 > You need to explain what I had to guess from the context because it = was > not clear. >=20 > In the example appear ipfixMeteringProcessCacheId values and nobody > knows where they come from. I had to guess that there are two Metering > Processes. This should be explained somewhere. >=20 > >>> (ipfixObservationPointTable) described in the next section. If > an > >>> Observation Point cannot be given the > >> > >> What do you mean by "cannot be given"? > > > > If you think of a concentrator that merges things you may not be = able > to > > specify a observation domain. Then you cannot tell the observation > point is > > this or that. >=20 > "cannot be given" leaves open why the Observation Point cannot be > identified, and I wondered what the reasons could be. >=20 > If you think of information that is not available, then consider: > "If the Observations Points are unknown, the > ipfixObservationPointGroupReference MUST be zero(0)." > or > "If the Observations Points are unspecified, the > ipfixObservationPointGroupReference MUST be zero(0)." >=20 >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz ------=_NextPart_000_00B5_01C93DCF.891C2EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMTAzMTUxNjMyWjAjBgkqhkiG9w0BCQQxFgQU8ymVXFJiKZZYnLReMN30mfwOmBcwgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGAhR145lUmpSPt /hd5RrH4IhsaBJn6ltnCdh/Oq0NklT2lOgXVZHJI8AJAj3QuaxcKve/e+HSN8UmvnaWyz2IVRwYh k0C+deNbLT5dpayNrRlvXRGuKR++iEEGTicX6U1uMGK5xKVZNZkGM7NYg1Z2ffG7zr3lGy4z0w25 HWjFdMYAAAAAAAA= ------=_NextPart_000_00B5_01C93DCF.891C2EE0-- --===============0977704070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0977704070==-- From ipfix-bounces@ietf.org Mon Nov 3 07:18:27 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FF9128C283; Mon, 3 Nov 2008 07:18:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C979D28C283 for ; Mon, 3 Nov 2008 07:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0sbbD-wrDJ8 for ; Mon, 3 Nov 2008 07:18:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5D4AC28C293 for ; Mon, 3 Nov 2008 07:16:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4850A2C0004E3; Mon, 3 Nov 2008 16:16:45 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Ey1RNM5whf; Mon, 3 Nov 2008 16:16:45 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 15F2F2C000305; Mon, 3 Nov 2008 16:16:35 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Nov 2008 16:16:32 +0100 Message-ID: <547F018265F92642B577B986577D671C44164A@VENUS.office> In-Reply-To: <490B3993.1040504@net.in.tum.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 Thread-Index: Ack7ej1aACDkSkogQWamOlkOV3OtdgCTIzPA References: <48B7C105.8070708@informatik.uni-tuebingen.de> <547F018265F92642B577B986577D671C441471@VENUS.office> <490B3993.1040504@net.in.tum.de> From: "Thomas Dietz" To: "Gerhard Muenz" Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0977704070==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============0977704070== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B5_01C93DCF.891C2EE0" This is a multipart message in MIME format. ------=_NextPart_000_00B5_01C93DCF.891C2EE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Gerhard, Looks like I am editing this draft for such a long time that I don't see = the obvious. You are absolutely right when you say we can join these two = tables. I tried to address all your remaining issues and will submit a new = version in a few minutes. Best Regards, Thomas --=20 Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu NEC Europe Limited Registered in England 2832014 Registered Office: NEC House, 1 Victoria Road, London W3 6BL > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > Sent: Freitag, 31. Oktober 2008 18:00 > To: Thomas Dietz > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mib-04 >=20 >=20 > Thomas, >=20 > Thomas Dietz wrote: > > sorry for the late reply. See my comments inline... >=20 > >> Dear all, > >> > >> Please find comments on draft-ietf-ipfix-mib-04 below. > >> > >> Currently, we have ipfixTransportSessionTable which does not = provide > >> any > >> information about the role of the given device within the transport > >> session. We do not know if the device is exporter or collector. > >> > >> On the other hand, you define "directional" tables for the > Templates: > >> ipfixExportedTemplateTable > >> ipfixExportedTemplateDefinitionTable > >> ipfixCollectedTemplateTable > >> ipfixCollectedTemplateDefinitionTable > >> > >> Is there any specific reason? > >> > > > > Yes there is... see below > > > >> There are two alternatives which require fewer tables: > >> 1) One could add an entry about the role of the device to the > >> ipfixTransportSessionTable, for example in form of a field with > values > >> "exporter" and "collector". As the Templates are scoped to a given > >> Transport Session, it is clear which Templates are exported and > which > >> Templates are collected. So we would have only three tables instead > of > >> five: > >> ipfixTransportSessionTable > >> ipfixTemplateTable > >> ipfixTemplateDefinitionTable > >> > > > > That the way we had it before, more or less. >=20 > No, it is not the same as you had before. In the previous version, the > entries in the Transport Session table did not include any information > about at which endpoint of the Transport Session the device is = located. > That's why it could not work. >=20 > I propose to add a column to the Transport Session table that says > "collector endpoint" or "exporter endpoint". >=20 > > The problem is that a device > > potentially can be a collector and an exporter at the same time. We > could > > collect a template with a Observation domain x and a template id y > which is > > not necessarily the same as the template with observation domain x > and > > template id y that we export. The template Ids are only unique at = the > > exporting device. The same is true for the observation domain ids. = So > having > > one table for the templates (ipfixTemplateTable) und in consequence > for the > > template definitions (ipfixTemplateDefinitionTable) does not work. >=20 > There should not be a problem with the additional column I propose > because the Transport Session entry provides the necessary separation > between "exporter" and "collector". >=20 > The ipfixTemplateTable has the following indexes: >=20 > ipfixTransportSessionIndex, > ipfixObservationDomainId >=20 > and the ipfixTemplateDefinitionTable has: >=20 > ipfixTransportSessionIndex, > ipfixObservationDomainId, > ipfixTemplateId >=20 > In both tables, ipfixTransportSessionIndex is index. So, as far as I > understand, this means that there is no problem to use identical = values > for ODID and the same Template ID for different Transport Sessions. >=20 > And there is another disadvantage with your proposal: > It is not possible to know from the Transport Session table if the > device is Exporter or Collector for a given Transport Session. > You must first search the ipfixExportedTemplateTable and the > ipfixCollectedTemplateTable to know that. > If there are no Templates received or exported at all, you will never > know. In this case, the only solution is too match the IP addresses of > the Transport Session table with known IP addresses of the device. I = do > not think that this is a good solution. >=20 > With the proposed column, you get the information directly. >=20 > >> 2) Or, one could split the ipfixTransportSessionTable into: > >> - ipfixOutgoingTransportSessionTable for Transport Sessions where > the > >> given device is exporter. > >> - ipfixIncomingTransportSessionTable for Transport Sessions where > the > >> given device is collector. > >> Again, we only need two tables for the Templates: > >> ipfixTemplateTable > >> ipfixTemplateDefinitionTable > >> > > > > We could split the transport session table into 2 but for the reason > > explained above we still cannot collapse the template and template > > definition table into one. But I don't see the point why to split = the > > transport session table without gaining anything. >=20 > You are right that this does not work. The reason is that we would = need > different sets of indexes for incoming and outgoing Templates in the > ipfixTemplateTable: > - ipfixIncomingTransportSessionIndex and ipfixObservationDomainId for > incoming, and > - ipfixOutgoingTransportSessionIndex and ipfixObservationDomainId for > outgoing. >=20 > >> Why is a Transport Session group restricted to the output of a > single > >> cache? > > > > Because that's what a transport session group is for. Export from a > single > > cache to different destinations in different configurations. > > Primary/Secondary for failover, in Parallel, ... >=20 > Ok. >=20 > When I asked the question, I thought that there was a one-to-one > mapping > between an entry in the Export table and an Exporting Process. But = this > is not the case. >=20 > >> Can you explain this example? > >> > >> There are two Metering Processes? And the output is sent to > different > >> primary collectors? And in case of a failure, each collector serves > as > >> backup for the other? > > > > > > Absolutely right. So what do I need to explain??? >=20 > You need to explain what I had to guess from the context because it = was > not clear. >=20 > In the example appear ipfixMeteringProcessCacheId values and nobody > knows where they come from. I had to guess that there are two Metering > Processes. This should be explained somewhere. >=20 > >>> (ipfixObservationPointTable) described in the next section. If > an > >>> Observation Point cannot be given the > >> > >> What do you mean by "cannot be given"? > > > > If you think of a concentrator that merges things you may not be = able > to > > specify a observation domain. Then you cannot tell the observation > point is > > this or that. >=20 > "cannot be given" leaves open why the Observation Point cannot be > identified, and I wondered what the reasons could be. >=20 > If you think of information that is not available, then consider: > "If the Observations Points are unknown, the > ipfixObservationPointGroupReference MUST be zero(0)." > or > "If the Observations Points are unspecified, the > ipfixObservationPointGroupReference MUST be zero(0)." >=20 >=20 > Regards, > Gerhard >=20 > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz ------=_NextPart_000_00B5_01C93DCF.891C2EE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMTAzMTUxNjMyWjAjBgkqhkiG9w0BCQQxFgQU8ymVXFJiKZZYnLReMN30mfwOmBcwgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGAhR145lUmpSPt /hd5RrH4IhsaBJn6ltnCdh/Oq0NklT2lOgXVZHJI8AJAj3QuaxcKve/e+HSN8UmvnaWyz2IVRwYh k0C+deNbLT5dpayNrRlvXRGuKR++iEEGTicX6U1uMGK5xKVZNZkGM7NYg1Z2ffG7zr3lGy4z0w25 HWjFdMYAAAAAAAA= ------=_NextPart_000_00B5_01C93DCF.891C2EE0-- --===============0977704070== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0977704070==-- From ipfix-bounces@ietf.org Mon Nov 3 07:30:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F045A3A6BCB; Mon, 3 Nov 2008 07:30:03 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6BE053A6BE7; Mon, 3 Nov 2008 07:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103153001.6BE053A6BE7@core3.amsl.com> Date: Mon, 3 Nov 2008 07:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-05.txt Pages : 58 Date : 2008-11-03 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03072019.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 07:30:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F045A3A6BCB; Mon, 3 Nov 2008 07:30:03 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6BE053A6BE7; Mon, 3 Nov 2008 07:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103153001.6BE053A6BE7@core3.amsl.com> Date: Mon, 3 Nov 2008 07:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-05.txt Pages : 58 Date : 2008-11-03 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03072019.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 08:00:07 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87DB3A6BED; Mon, 3 Nov 2008 08:00:06 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AF1B3A6943; Mon, 3 Nov 2008 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103160001.6AF1B3A6943@core3.amsl.com> Date: Mon, 3 Nov 2008 08:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-01.txt Pages : 26 Date : 2008-11-03 This document describes a framework for an IPFIX Mediation. This framework details an IPFIX Mediation reference model and the components of the IPFIX Mediation device (IPFIX Mediator). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03075446.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 08:00:07 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87DB3A6BED; Mon, 3 Nov 2008 08:00:06 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AF1B3A6943; Mon, 3 Nov 2008 08:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103160001.6AF1B3A6943@core3.amsl.com> Date: Mon, 3 Nov 2008 08:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Mediation: Framework Author(s) : A. Kobayashi, et al. Filename : draft-ietf-ipfix-mediators-framework-01.txt Pages : 26 Date : 2008-11-03 This document describes a framework for an IPFIX Mediation. This framework details an IPFIX Mediation reference model and the components of the IPFIX Mediation device (IPFIX Mediator). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-mediators-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-03075446.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 08:22:19 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C153A68F6; Mon, 3 Nov 2008 08:22:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566623A68F6 for ; Mon, 3 Nov 2008 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF8ZsN-3FR5g for ; Mon, 3 Nov 2008 08:22:17 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3D0183A699D for ; Mon, 3 Nov 2008 08:22:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2B35F2C0008DF for ; Mon, 3 Nov 2008 17:22:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPaMdm+prgGO for ; Mon, 3 Nov 2008 17:22:04 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id F19BE2C000305 for ; Mon, 3 Nov 2008 17:21:58 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Nov 2008 17:21:57 +0100 Message-ID: <547F018265F92642B577B986577D671C441678@VENUS.office> In-Reply-To: <20081103153001.6BE053A6BE7@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt Thread-Index: Ack9yo+/4u5AIYzMRxO+31undxGo8wABTM5A References: <20081103153001.6BE053A6BE7@core3.amsl.com> From: "Thomas Dietz" To: Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298019473==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============1298019473== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C0_01C93DD8.AC93FDE0" This is a multipart message in MIME format. ------=_NextPart_000_00C0_01C93DD8.AC93FDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the MIB draft. With this draft I addressed the issues that were raised by Gerhard. Changes (among minor things): * Added ipfixTransportSessionMode in the Transport Session table * Joined ipfixExportedTemplateTable and ipfixCollectedTemplateTable into one table * Joined the corresponding ...DefinitionTables to one table * Added ipfixTemplateDefinitionEnterprise to give the enterprise number for enterprise specific IEs Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 6221From ipfix-bounces@ietf.org Mon Nov 3 08:22:19 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C153A68F6; Mon, 3 Nov 2008 08:22:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566623A68F6 for ; Mon, 3 Nov 2008 08:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF8ZsN-3FR5g for ; Mon, 3 Nov 2008 08:22:17 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 3D0183A699D for ; Mon, 3 Nov 2008 08:22:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 2B35F2C0008DF for ; Mon, 3 Nov 2008 17:22:04 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPaMdm+prgGO for ; Mon, 3 Nov 2008 17:22:04 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id F19BE2C000305 for ; Mon, 3 Nov 2008 17:21:58 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Nov 2008 17:21:57 +0100 Message-ID: <547F018265F92642B577B986577D671C441678@VENUS.office> In-Reply-To: <20081103153001.6BE053A6BE7@core3.amsl.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt Thread-Index: Ack9yo+/4u5AIYzMRxO+31undxGo8wABTM5A References: <20081103153001.6BE053A6BE7@core3.amsl.com> From: "Thomas Dietz" To: Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mib-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298019473==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multipart message in MIME format. --===============1298019473== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C0_01C93DD8.AC93FDE0" This is a multipart message in MIME format. ------=_NextPart_000_00C0_01C93DD8.AC93FDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the MIB draft. With this draft I addressed the issues that were raised by Gerhard. Changes (among minor things): * Added ipfixTransportSessionMode in the Transport Session table * Joined ipfixExportedTemplateTable and ipfixCollectedTemplateTable into one table * Joined the corresponding ...DefinitionTables to one table * Added ipfixTemplateDefinitionEnterprise to give the enterprise number for enterprise specific IEs Best Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@nw.neclab.eu NEC Europe Ltd. Phone: +49 6221 4342-128 NEC Laboratories Europe Fax: +49 62 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu 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: Montag, 3. November 2008 16:30 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-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 IP Flow > Information Export > Author(s) : T. Dietz, et al. > Filename : draft-ietf-ipfix-mib-05.txt > Pages : 58 > Date : 2008-11-03 > > This document defines managed objects for IP Flow Information Export > (IPFIX). These objects provide information for monitoring IPFIX > Exporters and IPFIX Collectors including the basic configuration > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_00C0_01C93DD8.AC93FDE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlvb21 4342-155 Network Research Division Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.nw.neclab.eu 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: Montag, 3. November 2008 16:30 > To: i-d-announce@ietf.org > Cc: ipfix@ietf.org > Subject: [IPFIX] I-D Action:draft-ietf-ipfix-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 IP Flow > Information Export > Author(s) : T. Dietz, et al. > Filename : draft-ietf-ipfix-mib-05.txt > Pages : 58 > Date : 2008-11-03 > > This document defines managed objects for IP Flow Information Export > (IPFIX). These objects provide information for monitoring IPFIX > Exporters and IPFIX Collectors including the basic configuration > information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_00C0_01C93DD8.AC93FDE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJQjCCA+Qw ggNNoAMCAQICEDa4sZCtixKGSSaZM9bagsQwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wODA3MDIw ODM2MDFaFw0xMDA3MDIwODQ0MjNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTh CrAuhw+t6t/QUmSQeUF7GDBuEuxpMLNqbzgRs9gEGYO53/UItPlG3geplCycdPpIvsA3XTc8aP59 2nJiLGG6HvAeYk17PAXskxM53P8Yoc/2eW5tC/5tJFhpqSskIjLtk2MgXMqCTLqebbTwHXgrFPi+ cHWnf5AZAmVJgf6xAgMBAAGjggFzMIIBbzATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQURhrnkuxqesR4+3QmPWHQ1bkqwvQwgeEGA1Ud HwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDcpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQyg3KS5jcmwwEgYJKwYB BAGCNxUBBAUCAwcABzAjBgkrBgEEAYI3FQIEFgQUAYECJEvESazUYcsNeVjVFsA2NlowDQYJKoZI hvcNAQEFBQADgYEAdOlEobqvaymfB0d0+KPSaTdugLB65Q7IXPovoD0bZ7lkGkt3XFgq8iPJGlwk /bHq6fJ+wJ2QC15BrkjptwQA3EdDh+uvV1GFI06gl0xpjpcWS/sgY6wRjYOWiNQHkHQJJpBmuKPU QrMUc/tOeD6V7CeIfHzVNkhc41uNwsgJzWwwggVWMIIEv6ADAgECAgoVesVAAAcAAAWPMA0GCSqG SIb3DQEBBQUAMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UE BhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhE MQwwCgYDVQQDEwNORUMwHhcNMDgwNzAyMTM0MTAxWhcNMDkwNzAyMTM0MTAxWjBtMRYwFAYKCZIm iZPyLGQBGRYGb2ZmaWNlMRIwEAYDVQQLEwlORUMgVXNlcnMxFTATBgNVBAMTDFRob21hcyBEaWV0 ejEoMCYGCSqGSIb3DQEJARYZVGhvbWFzLkRpZXR6QG53Lm5lY2xhYi5ldTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA1gLeHVY6xKNSRdDt08OzatHJx7FyPzQYUncJuZ7w+KaBCK7KL2iGQno1 r11M+6pHMAroyc8j1V/I0Teux2aU0ULxvPHRagTU2bXx6Dh3HOLZGXzfYjnZxj9apkD9OvkK5M/C MH6eqdwyQhf36I/dw4S0qUTJJ7yTylzPM9LCeMMCAwEAAaOCAvMwggLvMBcGCSsGAQQBgjcUAgQK HggAVQBzAGUAcjAdBgNVHQ4EFgQUd57ctaS+0UpuVhIU5o1+yoKLm4cwCwYDVR0PBAQDAgWgMB8G A1UdIwQYMBaAFEYa55LsanrEePt0Jj1h0NW5KsL0MIHhBgNVHR8EgdkwgdYwgdOggdCggc2GgaFs ZGFwOi8vL0NOPU5FQyg3KSxDTj1zb2wsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9b2ZmaWNlP2NlcnRpZmljYXRlUmV2b2Nh dGlkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMTAzMTYyMTU3WjAjBgkqhkiG9w0BCQQxFgQUFDZvB1ImOE//Wd9j/u6PgHrf+0swgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGApRUC2egiOum0 w0+tKIUS6NQ4Ijc+fBj6Mmir+E9+8eVa2+7IhiWjWexrlUez1KtkeUI2SSrsDcdALzgLFhiriEKu nxTm1xfOrdN+zEfaYESWWRfDVgGW2DcXAyZONooU73r0kgMzM/JuOk49HBlC1xo415MYdt8ENoEw EreUvksAAAAAAAA= ------=_NextPart_000_00C0_01C93DD8.AC93FDE0-- --===============1298019473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1298019473==-- vbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYnaHR0cDovL3Nv bC5vZmZpY2UvQ2VydEVucm9sbC9ORUMoNykuY3JsMIHtBggrBgEFBQcBAQSB4DCB3TCBmgYIKwYB BQUHMAKGgY1sZGFwOi8vL0NOPU5FQyxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMs Q049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZpY2U/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwPgYIKwYBBQUHMAKGMmh0dHA6Ly9z b2wub2ZmaWNlL0NlcnRFbnJvbGwvc29sLm9mZmljZV9ORUMoNykuY3J0MCkGA1UdJQQiMCAGCisG AQQBgjcKAwQGCCsGAQUFBwMEBggrBgEFBQcDAjBCBgNVHREEOzA5oBwGCisGAQQBgjcUAgOgDgwM ZGlldHpAb2ZmaWNlgRlUaG9tYXMuRGlldHpAbncubmVjbGFiLmV1MEQGCSqGSIb3DQEJDwQ3MDUw DgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzANBgkq hkiG9w0BAQUFAAOBgQCDEErnWoyLLK17Yuo0tIUYlxLLFu//Nkc1BxeiTHCJvYFkVQId15DZH9k3 dI7O1+fmahqUXG/EzbtEu5yx0JiwNJhIo8A58QzkSfvS8Kd83QMqI074AAIvvPE1XgLPZRwz+6iq r5nZmG0tqi2smxHQZ9gpdHab0Kfkj8BhKNeGyzGCA3UwggNxAgEBMIGDMHUxJDAiBgkqhkiG9w0B CQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYD VQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCChV6xUAABwAA BY8wCQYFKw4DAhoFAKCCAkcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDgxMTAzMTYyMTU3WjAjBgkqhkiG9w0BCQQxFgQUFDZvB1ImOE//Wd9j/u6PgHrf+0swgZQG CSsGAQQBgjcQBDGBhjCBgzB1MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUx CzAJBgNVBAYTAkRFMQswCQYDVQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYD VQQLEwJIRDEMMAoGA1UEAxMDTkVDAgoVesVAAAcAAAWPMIGWBgsqhkiG9w0BCRACCzGBhqCBgzB1 MSQwIgYJKoZIhvcNAQkBFhVjb3JlYWRtQG5ldGxhYi5uZWMuZGUxCzAJBgNVBAYTAkRFMQswCQYD VQQHEwJIRDEYMBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMQswCQYDVQQLEwJIRDEMMAoGA1UEAxMD TkVDAgoVesVAAAcAAAWPMIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgB ZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIGApRUC2egiOum0 w0+tKIUS6NQ4Ijc+fBj6Mmir+E9+8eVa2+7IhiWjWexrlUez1KtkeUI2SSrsDcdALzgLFhiriEKu nxTm1xfOrdN+zEfaYESWWRfDVgGW2DcXAyZONooU73r0kgMzM/JuOk49HBlC1xo415MYdt8ENoEw EreUvksAAAAAAAA= ------=_NextPart_000_00C0_01C93DD8.AC93FDE0-- --===============1298019473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1298019473==-- From ipfix-bounces@ietf.org Mon Nov 3 09:04:24 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA3B3A6B62; Mon, 3 Nov 2008 09:04:24 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174AD3A6B6B for ; Mon, 3 Nov 2008 09:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+fNNNPBzti8 for ; Mon, 3 Nov 2008 09:04:22 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DCBD43A6B62 for ; Mon, 3 Nov 2008 09:04:21 -0800 (PST) Received: from localhost ([IPv6:2001:fa8:1000:0:e08f:6d91:b7c1:75e4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mA3H4I8H077455 for ; Tue, 4 Nov 2008 02:04:18 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 04 Nov 2008 01:57:44 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20081103160001.6AF1B3A6943@core3.amsl.com> References: <20081103160001.6AF1B3A6943@core3.amsl.com> Message-Id: <20081104015707.BA84.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 04 Nov 2008 02:04:18 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, I submitted -01 version mediator framework draft. Changes from -00 to -01 version are as follows: Table of Contents was changed in accordance with that of IPFIX-ARCH draft. - Added "IPFIX Mediation Reference Model" section. It shows the high level figure of IPFIX Mediation - Changed current section 3 "Architecture Model" to "IPFIX Mediation Functional and Logical Blocks" - Added subsection 4.5 "Flow Expiration". - Added subsection 4.6 "Information Model". - Added subsection 4.7 "Examples" - removed "Mediator Metering Process" In -00 version, Intermediate Process covered Mediator Metering Process and IPFIX File Writer/Reader. But, in -01 version, the position of IPFIX File Writer/Reader becomes equivalent to that of Exporting/Collecting Process. So, Mediator Metering Process became meaningless. - Added subsection 4.3.4. "Correlation Function". - Added the description of Time/Space Composition in Aggregation Function. - removed section "Guideline for IPFIX Protocol for IPFIX Mediators". It will be continued in another Mediator Protocol draft, in near future. Regards, Atsushi Kobayashi On Mon, 3 Nov 2008 08:00:01 -0800 (PST) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-01.txt > Pages : 26 > Date : 2008-11-03 > > This document describes a framework for an IPFIX Mediation. This > framework details an IPFIX Mediation reference model and the > components of the IPFIX Mediation device (IPFIX Mediator). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 3 09:04:24 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA3B3A6B62; Mon, 3 Nov 2008 09:04:24 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174AD3A6B6B for ; Mon, 3 Nov 2008 09:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+fNNNPBzti8 for ; Mon, 3 Nov 2008 09:04:22 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id DCBD43A6B62 for ; Mon, 3 Nov 2008 09:04:21 -0800 (PST) Received: from localhost ([IPv6:2001:fa8:1000:0:e08f:6d91:b7c1:75e4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mA3H4I8H077455 for ; Tue, 4 Nov 2008 02:04:18 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 04 Nov 2008 01:57:44 +0900 From: Atsushi Kobayashi To: ipfix@ietf.org In-Reply-To: <20081103160001.6AF1B3A6943@core3.amsl.com> References: <20081103160001.6AF1B3A6943@core3.amsl.com> Message-Id: <20081104015707.BA84.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 04 Nov 2008 02:04:18 +0900 (JST) Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-framework-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, I submitted -01 version mediator framework draft. Changes from -00 to -01 version are as follows: Table of Contents was changed in accordance with that of IPFIX-ARCH draft. - Added "IPFIX Mediation Reference Model" section. It shows the high level figure of IPFIX Mediation - Changed current section 3 "Architecture Model" to "IPFIX Mediation Functional and Logical Blocks" - Added subsection 4.5 "Flow Expiration". - Added subsection 4.6 "Information Model". - Added subsection 4.7 "Examples" - removed "Mediator Metering Process" In -00 version, Intermediate Process covered Mediator Metering Process and IPFIX File Writer/Reader. But, in -01 version, the position of IPFIX File Writer/Reader becomes equivalent to that of Exporting/Collecting Process. So, Mediator Metering Process became meaningless. - Added subsection 4.3.4. "Correlation Function". - Added the description of Time/Space Composition in Aggregation Function. - removed section "Guideline for IPFIX Protocol for IPFIX Mediators". It will be continued in another Mediator Protocol draft, in near future. Regards, Atsushi Kobayashi On Mon, 3 Nov 2008 08:00:01 -0800 (PST) Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > > Title : IPFIX Mediation: Framework > Author(s) : A. Kobayashi, et al. > Filename : draft-ietf-ipfix-mediators-framework-01.txt > Pages : 26 > Date : 2008-11-03 > > This document describes a framework for an IPFIX Mediation. This > framework details an IPFIX Mediation reference model and the > components of the IPFIX Mediation device (IPFIX Mediator). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-framework-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 3 15:30:04 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ECC28C3C1; Mon, 3 Nov 2008 15:30:04 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5219B28C3B1; Mon, 3 Nov 2008 15:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103233001.5219B28C3B1@core3.amsl.com> Date: Mon, 3 Nov 2008 15:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-01.txt Pages : 22 Date : 2008-11-3 This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3152945.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Mon Nov 3 15:30:04 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5ECC28C3C1; Mon, 3 Nov 2008 15:30:04 -0800 (PST) X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5219B28C3B1; Mon, 3 Nov 2008 15:30:00 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081103233001.5219B28C3B1@core3.amsl.com> Date: Mon, 3 Nov 2008 15:30:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-export-per-sctp-stream-01.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Export per SCTP Stream Author(s) : B. Claise, P. Aitken, A. Johnson, G. Muenz Filename : draft-ietf-ipfix-export-per-sctp-stream-01.txt Pages : 22 Date : 2008-11-3 This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-export-per-sctp-stream-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-export-per-sctp-stream-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-11-3152945.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Tue Nov 4 14:45:38 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E97128C2A7; Tue, 4 Nov 2008 14:45:38 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BF83A6CF3 for ; Tue, 4 Nov 2008 14:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-2.707, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsZ5nh0c2siy for ; Tue, 4 Nov 2008 14:45:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A36383A6934 for ; Tue, 4 Nov 2008 14:45:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 535FE9DD40 for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmisCOJ4HtLF for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 33A8E9DD36 for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) Message-ID: <4910D077.9030201@auckland.ac.nz> Date: Wed, 05 Nov 2008 11:45:11 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] New Drafts - please check the changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: The drafts listed below have been recently published, following their WG Last Calls. If you raised any concerns about them earlier, please check the new versions and let us know (on this list) if you have any remaining issues. Provided no further issues are raised before our session at IETF 73 in Minneapolis, or at that session, we will write up their Shepherding reports and submit them to IESG for publication as RFCs. - draft-ietf-ipfix-mib-05.txt - draft-ietf-ipfix-export-per-sctp-stream-01.txt - draft-ietf-ipfix-exporting-type-02.txt - draft-ietf-ipfix-file-03.txt Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 4 14:45:38 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E97128C2A7; Tue, 4 Nov 2008 14:45:38 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BF83A6CF3 for ; Tue, 4 Nov 2008 14:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[AWL=-2.707, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsZ5nh0c2siy for ; Tue, 4 Nov 2008 14:45:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id A36383A6934 for ; Tue, 4 Nov 2008 14:45:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 535FE9DD40 for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmisCOJ4HtLF for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 33A8E9DD36 for ; Wed, 5 Nov 2008 11:45:12 +1300 (NZDT) Message-ID: <4910D077.9030201@auckland.ac.nz> Date: Wed, 05 Nov 2008 11:45:11 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] New Drafts - please check the changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: The drafts listed below have been recently published, following their WG Last Calls. If you raised any concerns about them earlier, please check the new versions and let us know (on this list) if you have any remaining issues. Provided no further issues are raised before our session at IETF 73 in Minneapolis, or at that session, we will write up their Shepherding reports and submit them to IESG for publication as RFCs. - draft-ietf-ipfix-mib-05.txt - draft-ietf-ipfix-export-per-sctp-stream-01.txt - draft-ietf-ipfix-exporting-type-02.txt - draft-ietf-ipfix-file-03.txt Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From iurf-wef1986@5050shot.com Fri Nov 7 22:35:53 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A453A68F3 for ; Fri, 7 Nov 2008 22:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.082 X-Spam-Level: X-Spam-Status: No, score=-24.082 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de3i-JhdkeCp for ; Fri, 7 Nov 2008 22:35:53 -0800 (PST) Received: from pool-71-118-159-201.lsanca.dsl-w.verizon.net (pool-71-118-159-201.lsanca.dsl-w.verizon.net [71.118.159.201]) by core3.amsl.com (Postfix) with ESMTP id CD6773A6974 for ; Fri, 7 Nov 2008 22:35:52 -0800 (PST) To: Subject: important information From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081108063552.CD6773A6974@core3.amsl.com> Date: Fri, 7 Nov 2008 22:35:52 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

?2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ipfix-bounces@ietf.org Mon Nov 10 21:01:08 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B3C3A698E; Mon, 10 Nov 2008 21:01:08 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F493A68E3 for ; Mon, 10 Nov 2008 21:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2P0-LvrpbpC for ; Mon, 10 Nov 2008 21:01:06 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id C58F23A67EA for ; Mon, 10 Nov 2008 21:01:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F20939DF9A for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK+yu82lqrrP for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CB87C9DF8E for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) Message-ID: <49191186.3000203@auckland.ac.nz> Date: Tue, 11 Nov 2008 18:00:54 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Proposed changes to IPFIX milestones X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put out meeting Agenda on the IETF Meeting Agendas page. If you're presenting, please email me your slides *well before* the meeting so I can get them onto the Meeting Agendas page too! It's quite some time since we updated our WG milestones! We will discuss them at our Minneapolis meeting, I propose the following changes: Key: -> marks changes, ++ marks new milestones Jan 2008 Publish Internet draft on IPFIX Mediation Problem Statement -> Done Publish Internet draft on IPFIX Mediators: Problem Statement ++ Done Publish Internet draft on IPFIX Mediators: Framework Jan 2008 Submit File Format draft to IESG as Std track RFC -> Jan 2009 Mar 2008 Submit IPFIX MIB draft to IESG as Std track RFC -> Jan 2009 Jun 2008 Submit Type Export draft to IESG as Std track RFC -> Jan 2009 Submit Exporting Type Information to IESG as Std track RFC Jun 2008 Submit Single SCTP Stream draft to IESG as Info RFC -> Jan 2009 Oct 2008 Submit Configuration Data Model draft to IESG as Std RFC -> Feb 2009 Publish Configuration Information Model draft (Std track) ++ Apr 2009 Submit Config Info Model draft to IESG ++ Mar 2009 Publish Configuration Data Model draft (in YANG, experimental) ++ Oct 2009 Submit Config Data Model draft to IESG Oct 2008 Submit Mediation Problem draft to IESG as Info RFC -> Apr 2009 Submit IPFIX Mediators: Problem Statement draft to IESG ++ Jun 2009 Submit IPFIX Mediators: Framework draft to IESG Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 10 21:01:08 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B3C3A698E; Mon, 10 Nov 2008 21:01:08 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F493A68E3 for ; Mon, 10 Nov 2008 21:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2P0-LvrpbpC for ; Mon, 10 Nov 2008 21:01:06 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id C58F23A67EA for ; Mon, 10 Nov 2008 21:01:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F20939DF9A for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MK+yu82lqrrP for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CB87C9DF8E for ; Tue, 11 Nov 2008 18:01:00 +1300 (NZDT) Message-ID: <49191186.3000203@auckland.ac.nz> Date: Tue, 11 Nov 2008 18:00:54 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Subject: [IPFIX] Proposed changes to IPFIX milestones X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put out meeting Agenda on the IETF Meeting Agendas page. If you're presenting, please email me your slides *well before* the meeting so I can get them onto the Meeting Agendas page too! It's quite some time since we updated our WG milestones! We will discuss them at our Minneapolis meeting, I propose the following changes: Key: -> marks changes, ++ marks new milestones Jan 2008 Publish Internet draft on IPFIX Mediation Problem Statement -> Done Publish Internet draft on IPFIX Mediators: Problem Statement ++ Done Publish Internet draft on IPFIX Mediators: Framework Jan 2008 Submit File Format draft to IESG as Std track RFC -> Jan 2009 Mar 2008 Submit IPFIX MIB draft to IESG as Std track RFC -> Jan 2009 Jun 2008 Submit Type Export draft to IESG as Std track RFC -> Jan 2009 Submit Exporting Type Information to IESG as Std track RFC Jun 2008 Submit Single SCTP Stream draft to IESG as Info RFC -> Jan 2009 Oct 2008 Submit Configuration Data Model draft to IESG as Std RFC -> Feb 2009 Publish Configuration Information Model draft (Std track) ++ Apr 2009 Submit Config Info Model draft to IESG ++ Mar 2009 Publish Configuration Data Model draft (in YANG, experimental) ++ Oct 2009 Submit Config Data Model draft to IESG Oct 2008 Submit Mediation Problem draft to IESG as Info RFC -> Apr 2009 Submit IPFIX Mediators: Problem Statement draft to IESG ++ Jun 2009 Submit IPFIX Mediators: Framework draft to IESG Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 16 14:44:10 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879863A68BC; Sun, 16 Nov 2008 14:44:10 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8672C3A68BC for ; Sun, 16 Nov 2008 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o-K8sd1n36b for ; Sun, 16 Nov 2008 14:44:08 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 32FE23A6358 for ; Sun, 16 Nov 2008 14:44:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 329799D132 for ; Mon, 17 Nov 2008 11:44:05 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi6Jf0jG4Kv0 for ; Mon, 17 Nov 2008 11:44:05 +1300 (NZDT) Received: from [130.129.63.222] (unknown [130.129.63.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 60C239D128 for ; Mon, 17 Nov 2008 11:44:03 +1300 (NZDT) Message-ID: <4920A22D.8040303@auckland.ac.nz> Date: Mon, 17 Nov 2008 11:43:57 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've at last had time to catch up with the 'Problem Statement' and 'Framework' drafts for IPFIX mediators. I have a longish list of 'editorial' suggestions (see below), and one cautious comment .. Both these drafts have Informative references to three drafts (flow anonymisation, aggregation, and flow selection techniques). But Internet Drafts are "works in progress," and are supposed to have short lifetimes - which makes them unsuitable as references in an RFC. I agree that all three of these drafts add useful information to the current Mediators drafts; I wonder whether their 'important ideas' material could be moved into the Mediators drafts? That would be better, I feel, than trying to refer to them as Internet Drafts. Cheers, Nevil Now for the 'editorial' suggestions: [ s/old/new/ means "substitute new for old text," ?? means "if you think this would be better" ] Problem Statement Draft: Page 6, definition of IPFIX Mediation current: IPFIX Mediation is a function located between Exporting Processes and Collecting Processes. The IPFIX Mediation can be included in any IPFIX Devices. The IPFIX Mediation consists of a set of some of functions: * rerouting input Flow Records/Packet Reports to a appropriate Collecting Process suggested: IPFIX Mediation is a function located between Exporting Processes and Collecting Processes. IPFIX Mediation can be included in any IPFIX Devices. IPFIX Mediation consists of a set of some of functions: * rerouting input Flow Records/Packet Reports to ab appropriate Collecting Process current: * changing a transport protocol which carries IPFIX Messages suggested: * changing the transport protocol which carries IPFIX Messages Page 7, definition of Flow-Based Collector Selection current: Element and then selects Collector for each input Flow Record/ suggested: Element and then selects the Collector(s) for each input Flow Record/ Page 7, definition of IPFIX Proxy current: An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages from Original Exporter, and sends IPFIX Messages to one or more Collectors. It may alter a part of IPFIX Message in order to comply with IPFIX Protocol specifications. It may also change type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, and convert a legacy protocol message to an IPFIX Message, if necessary. suggested: An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages from an Original Exporter, and sends IPFIX Messages to one or more Collectors. It may alter a part of an IPFIX Message in order to comply with IPFIX Protocol specifications. It may also change the Message's transport protocol, such as UDP, TCP, SCTP and PR-SCTP, and may convert a legacy protocol message to an IPFIX Message if necessary. Page 8, definition of IPFIX Masquerading Proxy current: An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out a part of data of input Flow Records/Packet Reports according to suggested: An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out a part of the data in input Flow Records/Packet Reports according to Page 9, 3.2 Data Retention Are there EU standards we could reference to back up this section? Page 10, section 3.4 current: Recently, several networks seem to have shifted towards integrated networks, such as the Internet and MPLS, which includes IPv4, IPv6, and VPN traffic. Flow Records/Packet Reports of these types need to suggested: Recently, several networks seem to have shifted towards 'integrated' technologies such as Internet Protocols and MPLS (which includes IPv4, IPv6, and VPN traffic). Flow Records/Packet Reports of these types need to current: identification data, the RD (Route Distinguisher), ingress IF, suggested: identification data, the RD (Route Distinguisher), ingress interface, Page 12, section 4 s/networks can even be increased/networks could be increased/ ?? current: will increase by approximately 50% per year according to [TRAFGRW]. suggested: is likely to increase by approximately 50% per year [TRAFGRW]. s\kFlows/s\kFlow/s\ Page 13, section 4.2.1 s/one way to this/one way to do this/ s/There is an application/Operators could use one application/ Page 14: section 4.4 s/aggregation for one or more/aggregation of one or more/ current: o Space Composition within one Exporter In that case, the spatial range is within one Exporters. For example, the Flow Records observed at physical interfaces which belong to virtual interface by link aggregation can be composed to one Flow Records. o Space Composition within some Exporters In that case, the spatial range consists of some different Exporters. For example, the Flow Records observed at same domain, such as west area and east area of an ISP network, can be composed to one Flow Records. suggested: o Space Composition within one Exporter In that case, the spatial range is within one Exporter. For example, the Flow Records observed at physical interfaces which belong to a virtual interface by link aggregation can be composed into one-area Flow Records. o Space Composition within several Exporters In that case, the spatial range consists of several different Exporters. For example, Flow Records observed in the same domain, such as west area and east area of an ISP network, can be composed into one-area Flow Records. s/exported as merging data/exported as merged data/ Page 16, section 5.5 s/relayed to single/relayed to a single/ s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ Framework Draft Section 2: Check that definitions match those in Problem Statement after 'editing' changes are made! Page 9: s/[*]/[*Applications] ?? Page 10, Figure B: s/Process (es)/Process(es)/ 3 times -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 16 14:44:10 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879863A68BC; Sun, 16 Nov 2008 14:44:10 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8672C3A68BC for ; Sun, 16 Nov 2008 14:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8o-K8sd1n36b for ; Sun, 16 Nov 2008 14:44:08 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 32FE23A6358 for ; Sun, 16 Nov 2008 14:44:06 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 329799D132 for ; Mon, 17 Nov 2008 11:44:05 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi6Jf0jG4Kv0 for ; Mon, 17 Nov 2008 11:44:05 +1300 (NZDT) Received: from [130.129.63.222] (unknown [130.129.63.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 60C239D128 for ; Mon, 17 Nov 2008 11:44:03 +1300 (NZDT) Message-ID: <4920A22D.8040303@auckland.ac.nz> Date: Mon, 17 Nov 2008 11:43:57 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've at last had time to catch up with the 'Problem Statement' and 'Framework' drafts for IPFIX mediators. I have a longish list of 'editorial' suggestions (see below), and one cautious comment .. Both these drafts have Informative references to three drafts (flow anonymisation, aggregation, and flow selection techniques). But Internet Drafts are "works in progress," and are supposed to have short lifetimes - which makes them unsuitable as references in an RFC. I agree that all three of these drafts add useful information to the current Mediators drafts; I wonder whether their 'important ideas' material could be moved into the Mediators drafts? That would be better, I feel, than trying to refer to them as Internet Drafts. Cheers, Nevil Now for the 'editorial' suggestions: [ s/old/new/ means "substitute new for old text," ?? means "if you think this would be better" ] Problem Statement Draft: Page 6, definition of IPFIX Mediation current: IPFIX Mediation is a function located between Exporting Processes and Collecting Processes. The IPFIX Mediation can be included in any IPFIX Devices. The IPFIX Mediation consists of a set of some of functions: * rerouting input Flow Records/Packet Reports to a appropriate Collecting Process suggested: IPFIX Mediation is a function located between Exporting Processes and Collecting Processes. IPFIX Mediation can be included in any IPFIX Devices. IPFIX Mediation consists of a set of some of functions: * rerouting input Flow Records/Packet Reports to ab appropriate Collecting Process current: * changing a transport protocol which carries IPFIX Messages suggested: * changing the transport protocol which carries IPFIX Messages Page 7, definition of Flow-Based Collector Selection current: Element and then selects Collector for each input Flow Record/ suggested: Element and then selects the Collector(s) for each input Flow Record/ Page 7, definition of IPFIX Proxy current: An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages from Original Exporter, and sends IPFIX Messages to one or more Collectors. It may alter a part of IPFIX Message in order to comply with IPFIX Protocol specifications. It may also change type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, and convert a legacy protocol message to an IPFIX Message, if necessary. suggested: An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages from an Original Exporter, and sends IPFIX Messages to one or more Collectors. It may alter a part of an IPFIX Message in order to comply with IPFIX Protocol specifications. It may also change the Message's transport protocol, such as UDP, TCP, SCTP and PR-SCTP, and may convert a legacy protocol message to an IPFIX Message if necessary. Page 8, definition of IPFIX Masquerading Proxy current: An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out a part of data of input Flow Records/Packet Reports according to suggested: An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out a part of the data in input Flow Records/Packet Reports according to Page 9, 3.2 Data Retention Are there EU standards we could reference to back up this section? Page 10, section 3.4 current: Recently, several networks seem to have shifted towards integrated networks, such as the Internet and MPLS, which includes IPv4, IPv6, and VPN traffic. Flow Records/Packet Reports of these types need to suggested: Recently, several networks seem to have shifted towards 'integrated' technologies such as Internet Protocols and MPLS (which includes IPv4, IPv6, and VPN traffic). Flow Records/Packet Reports of these types need to current: identification data, the RD (Route Distinguisher), ingress IF, suggested: identification data, the RD (Route Distinguisher), ingress interface, Page 12, section 4 s/networks can even be increased/networks could be increased/ ?? current: will increase by approximately 50% per year according to [TRAFGRW]. suggested: is likely to increase by approximately 50% per year [TRAFGRW]. s\kFlows/s\kFlow/s\ Page 13, section 4.2.1 s/one way to this/one way to do this/ s/There is an application/Operators could use one application/ Page 14: section 4.4 s/aggregation for one or more/aggregation of one or more/ current: o Space Composition within one Exporter In that case, the spatial range is within one Exporters. For example, the Flow Records observed at physical interfaces which belong to virtual interface by link aggregation can be composed to one Flow Records. o Space Composition within some Exporters In that case, the spatial range consists of some different Exporters. For example, the Flow Records observed at same domain, such as west area and east area of an ISP network, can be composed to one Flow Records. suggested: o Space Composition within one Exporter In that case, the spatial range is within one Exporter. For example, the Flow Records observed at physical interfaces which belong to a virtual interface by link aggregation can be composed into one-area Flow Records. o Space Composition within several Exporters In that case, the spatial range consists of several different Exporters. For example, Flow Records observed in the same domain, such as west area and east area of an ISP network, can be composed into one-area Flow Records. s/exported as merging data/exported as merged data/ Page 16, section 5.5 s/relayed to single/relayed to a single/ s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ Framework Draft Section 2: Check that definitions match those in Problem Statement after 'editing' changes are made! Page 9: s/[*]/[*Applications] ?? Page 10, Figure B: s/Process (es)/Process(es)/ 3 times -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 17 03:09:03 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468963A6768; Mon, 17 Nov 2008 03:09:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC023A6768 for ; Mon, 17 Nov 2008 03:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBCBWE4ogBDV for ; Mon, 17 Nov 2008 03:08:59 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id BA4503A6403 for ; Mon, 17 Nov 2008 03:08:58 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id AE4CE47B59 for ; Mon, 17 Nov 2008 12:08:53 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9547B48C1 for ; Mon, 17 Nov 2008 12:08:53 +0100 (CET) Message-ID: <492150CD.4040101@net.in.tum.de> Date: Mon, 17 Nov 2008 12:09:01 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1458089146==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1458089146== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030702030500070303080007" This is a cryptographically signed message in MIME format. --------------ms030702030500070303080007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Atsushi, all, I reviewed the mediator problem statement draft. For me, the purpose of the draft is not quite clear. Is it to justify the need of IPFIX Mediators? Then, the focus should be more on monitoring situations that cannot be adequately handled without this intermediate box between exporters and collectors. If functionalities like configurable flow keys, flow selection, anonymization are realized on an IPFIX exporter directly, they can be considered as part of the Metering Process. So, there is no mediation involved. Therefore, I would restrict the usage of the term "mediation" to the IPFIX mediator case. Regards, Gerhard > Abstract > > Flow-based measurement is currently a popular method for various Remove "currently". We should assume that this is also valid in future. > network monitoring usages. The sharing of flow-based information > among orthogonal monitoring applications raises open issues in terms not sure what you mean by "orthogonal" > of scalability, reliability and flexibility that IPFIX Mediation may > help resolve. IPFIX Mediation reroutes, replicates, filters, > aggregates, correlates or modifies Flow Records or Packet Reports, or > changes a transport protocol. This document describes the You could introduce more clearly two classes of mediation: - mediation of content which changes the information, e.g. sampling, filtering, aggregation, anonymization,... - mediation of IPFIX transport which does not affect the information, e.g. rerouting, replication, changing the transport protocol etc. (storage would also fall into this category) > applicability of IPFIX Mediation and the problems that IPFIX > Mediation might encounter. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology and Definition . . . . . . . . . . . . . . . . . . 4 > 3. Flow-Based Mediation: Applicability Examples . . . . . . . . . 9 > 3.1. IPFIX Export Across Domains . . . . . . . . . . . . . . . 9 > 3.2. Data Retention . . . . . . . . . . . . . . . . . . . . . . 9 > 3.3. Interoperability between Legacy Protocols and IPFIX . . . 9 > 3.4. Rerouting Flow Records/Packet Reports . . . . . . . . . . 10 > 3.5. IPFIX Export from Branch Office . . . . . . . . . . . . . 10 > 3.6. Correlation of Flow Records/Packet Reports Information . . 11 > 4. Approaches to Scalability . . . . . . . . . . . . . . . . . . 12 > 4.1. Adjusting Sampling Rates . . . . . . . . . . . . . . . . . 12 > 4.2. Flow Aggregation . . . . . . . . . . . . . . . . . . . . . 12 > 4.2.1. Flow Aggregation on Original Exporters . . . . . . . . 13 > 4.2.2. Flow Aggregation on IPFIX Concentrators . . . . . . . 13 > 4.3. Time Composition . . . . . . . . . . . . . . . . . . . . . 13 > 4.4. Space Composition . . . . . . . . . . . . . . . . . . . . 14 > 4.5. Distributing Load among Collectors . . . . . . . . . . . . 14 > 4.6. Flow Selection Sampling . . . . . . . . . . . . . . . . . 14 > 5. Problems with using IPFIX Mediators . . . . . . . . . . . . . 15 > 5.1. Loss of Observation Point Information . . . . . . . . . . 15 > 5.2. Loss of Base Time Information . . . . . . . . . . . . . . 16 > 5.3. Loss of Option Template Information . . . . . . . . . . . 16 > 5.4. Observation Domain ID and Template ID Management . . . . . 16 > 5.5. Transport Sessions Management . . . . . . . . . . . . . . 16 > 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 > Intellectual Property and Copyright Statements . . . . . . . . . . 25 > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 2] > > Internet-Draft Mediation Problem Statement September 2008 > > > 1. Introduction > > > While the IPFIX requirements defined in [RFC3917] mention an > intermediate function, such as an IPFIX Proxy or an Concentrator, "...mention intermediate functions, such as IPFIX proxies and IPFIX concentrators [not sure if these terms should start with capital letters],..." > there is no document to define the function called IPFIX Mediation. > IPFIX Mediation is an additional function to suit the needs of some > measurement system. In this document, we describe several applicable Isn't IPFIX Mediation supposed to be an umbrella term which includes IPFIX concentrators and IPFIX proxies? > examples of IPFIX Mediation. Furthermore, we describe the problems > of IPFIX Mediation considering implementations. These problems can > be solved by additional specifications without influencing the > present IPFIX specification defined in [RFC5101]. "IPFIX protocol specification" > Section 2 describes the terminology used in this document. Section 3 > describes applicable examples of IPFIX Mediation. As more effective > cases, section 4 describes some usages of the IPFIX Mediation in > large-scale networks. Finally, section 5 describes the problems an > implementation of an IPFIX Mediation device might face. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 3] > > Internet-Draft Mediation Problem Statement September 2008 > > > 2. Terminology and Definition > > > The terms in this section are in line with those in the IPFIX > specification document [RFC5101] and the PSAMP specification document > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX What do you mean by "inline"? If you reuse terms from RFC5101, then you do not have to repeat them here. Only additional terms should appear in this section. Otherwise it is not clear which terms are new. > Mediation are also defined here. All these terms are capitalized in > this document. > > Observation Point > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. > > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Point > may be a superset of several other Observation Points. For > example, one Observation Point can be an entire line card. That > would be the superset of the individual Observation Points at the > line card's interfaces. > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IPFIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain IDs > also be unique per IPFIX Device. > > Flow Key > > Each of the fields that: > > 1. belong to the packet header (e.g., destination IP address), > > 2. are a property of the packet itself (e.g., packet length), > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > number), > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 4] > > Internet-Draft Mediation Problem Statement September 2008 > > > and that are used to define a Flow are termed Flow Keys. > > Flow Record > > A Flow Record contains information about a specific Flow that was > observed at an Observation Point. A Flow Record contains measured > properties of the Flow (e.g., the total number of bytes for all > the Flow's packets) and usually characteristic properties of the > Flow (e.g., source IP address). > > Packet Reports > > Packet Reports comprise a configurable subset of a packet's input > to the Selection Process, including the Packet Content, > information relating to its treatment (for example, the output > interface), and its associated selection state (for example, a > hash of the Packet Content). > > Exporting Process > > The Exporting Process sends Flow Records to one or more Collecting > Processes. The Flow Records are generated by one or more Metering > Processes. > > Exporter > > A device that hosts one or more Exporting Processes is termed an > Exporter. > > IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting Processes and arbitrary numbers of Observation > Points and Metering Processes. > > Collecting Process > > A Collecting Process receives Flow Records from one or more > Exporting Processes. The Collecting Process might process or > store received Flow Records, but such actions are out of scope for > this document. > > Collector > > A device that hosts one or more Collecting Processes is termed a > Collector. > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 5] > > Internet-Draft Mediation Problem Statement September 2008 > > > IPFIX Message > > An IPFIX Message is a message originating at the Exporting Process > that carries the IPFIX records of this Exporting Process and whose > destination is a Collecting Process. An IPFIX Message is > encapsulated at the transport layer. > > Information Element > > An Information Element is a protocol and encoding-independent > description of an attribute that may appear in an IPFIX Record. > The IPFIX information model [RFC5102] defines the base set of > Information Elements for IPFIX. The type associated with an > Information Element indicates constraints on what it may contain > and also determines the valid encoding mechanisms for use in > IPFIX. > > IPFIX Mediation > > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in Isn't it located between a Collecting Process and an Exporting Process? CP => Mediation => EP > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: "IPFIX Mediation consists of one or multiple of the following functions:" > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process BTW: this is a proxy function, so mediation is an umbrella term (see above) > * replicating input Flow Records/Packet Reports Not clear for what purpose Records should be replicated. Maybe add "in order to ....". > * filtering and selecting input Flow Records/Packet Reports remove "input"? > * aggregating input Flow Records/Packet Reports based on new Flow > Keys "based on a new set of Flow Key fields"? > * correlating a set of Flow Records/Packet Reports for creating > new Flow Records/Packet Reports with new metrics > > * modifying input Flow Records/Packet Reports remove "input"? > * changing a transport protocol which carries IPFIX Messages "changing the transport protocol" > The modification of Flow Records/Packet Reports includes these > functions: > > * changing the value of specified Information Elements > > * adding new Information Elements by deriving further Flow or > packet properties from existing fields or calculating new > > > > Kobayashi, et al. Expires March 30, 2009 [Page 6] > > Internet-Draft Mediation Problem Statement September 2008 > > > metrics > > * deleting specified Information Elements. I would move these bullet points below "modifying Flow Records/Packet Reports" in the preceding list because at that time the reader already wonders what "modify" could mean. > > IPFIX Mediation can be included in any devices, such as routers, > switches, NMS(Network Management Systems), or be deployed in > stand-alone devices. I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX Mediators. If performed on the original exporter, we already do have the Metering Process which can do all these things. > > Flow-Based Collector Selection > > The Flow-Based Collector Selection evaluates an input Flow Record/ > Packet Report based on the value of the specified Information > Element and then selects Collector for each input Flow Record/ > Packet Report. "Flow-Based Collector Selection is an IPFIX Mediation function which selects a Collector for every Flow Record/Packet Report. The selection of a Collector is based on match filters applied to record fields identified by Information Elements." > IPFIX Mediator > > An IPFIX Mediator contains one or more functions defined in IPFIX "one or more IPFIX Mediation functions" > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > device. It also contains one or more Collecting Processes and one What do you mean by "virtual"? > or more Exporting Processes. > > Original Exporter > > An Original Exporter is an IPFIX Device which hosts Observation > Points where IP packets can be directly observed. "where the metered IP packets are observed" > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX Mediator? Sending to multiple Collectors requires "replication" of IPFIX Messages, which implies that the included records are replicated as well. You mention "replication" in the case of IPFIX Distributor below. Maybe you want to mention it here as well? > Collectors. It may alter a part of IPFIX Message in order to "a part of the" > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, "change the transport protocol" > and convert a legacy protocol message to an IPFIX Message, if > necessary. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > Records/Packet Reports, aggregates them, then exports the > aggregated Flow Records. > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > Records/Packet Reports based on the result of Flow-Based Collector > Selection. It may filter or replicate input Flow Records/Packet > > > > Kobayashi, et al. Expires March 30, 2009 [Page 7] > > Internet-Draft Mediation Problem Statement September 2008 > > > Reports, if necessary. What is the difference between IPFIX Proxy and IPFIX Distributor? Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX Distributor handles individual records? > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > configured policies. It can thus, for example, hide the network > topology information or customers' IP addresses. Note: If you call this a "proxy", then my above distinction between IPFIX Proxy and IPFIX Distributor does not work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 8] > > Internet-Draft Mediation Problem Statement September 2008 > > > 3. Flow-Based Mediation: Applicability Examples > > > 3.1. IPFIX Export Across Domains > > > IPFIX export across administrative domains can be used to measure > traffic for wide-area traffic engineering, or to analyze the trend of > Internet traffic. In such cases, operators need to adhere to privacy > policies and prevent the transmission of confidential information. "prevent the transmission of confidential information" is unclear. Rather: "prevent the access to confidential traffic measurements by other operators" > Using an IPFIX Masquerading Proxy allows them to operate on Flow > Records safely by anonymizing and filtering them. IP Flow Who operates on the Flow Records? Anonymization rather makes it possible to give the Flow Records away to other operators without violating privacy policies. > anonymisation is described in [I-D.boschi-ipfix-anon] in detail. > > 3.2. Data Retention > > > Data retention refers to the storage of traffic data by service > providers and commercial organizations. According to European > Commission directives, operators are required to retain both IP and > voice traffic data, in wired and wireless networks, generated by end > users while using a service provider's services. The goal of data > retention is to ensure that call detail records and Flow Records are > available for the purpose of detection, investigation, and > prosecution of serious crimes, if necessary. The European Commission > directives define the following data retention services: > > o Fixed telephony (includes fixed voice, voicemail, and conference > and data calls) > > o Mobile telephony (includes mobile voice, voicemail, conference and > data calls, SMS, and MMS) > > o Internet telephony (includes every multimedia session associated > with IP multimedia services) > > o Internet e-mail > > o Internet access > > By monitoring Flow Records, IPFIX can fulfill these requirements of > Internet access services. Ok, but where is the link to IPFIX Mediation? > 3.3. Interoperability between Legacy Protocols and IPFIX > > > During the migration process from a legacy protocol such as NetFlow > [RFC3954] to IPFIX, both NetFlow and IPFIX Exporters will need to co- "are likely to coexist" > exist in the same network. An IPFIX Proxy which converts a legacy > protocol to IPFIX will allow operators to continue measuring Flows > from legacy Exporters, even after introducing IPFIX Collectors. > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 9] > > Internet-Draft Mediation Problem Statement September 2008 > > > 3.4. Rerouting Flow Records/Packet Reports > > > Recently, several networks seem to have shifted towards integrated remove "seem to" > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to "...of different networks need to..." > be analyzed separately and from different perspectives. However, > handling them separately without improving the capability of the > Collector is difficult. An IPFIX Distributor rerouting Flow Records/ > Packet Reports based on the result of Flow-based Collector Selection, > would be necessary. Thus, it allows individual Collectors related to "An IPFIX Distributor allows separating and rerouting Flow Records/Packet Reports from different networks to different Collectors based on Flow-based Collector Selection." > each network to analyze traffic data for their own specific purposes. > > As another example, in case of rerouting specific customer's Flow > Records, an IPFIX Distributor needs to identify each customer. As it rather needs to identify the customer networks > identification data, the RD (Route Distinguisher), ingress IF, What is "IF"? > peering AS number, or BGP next hop are listed. As shown in the Where are they listed? Proposed formulation: "RD (..), ingress interface, ....., may be evaluated to distinguish different customer networks." > following figure, the IPFIX Distributor reroutes Flow Records based remove "As shown" > on the RD value. This system allows each customer's traffic to be > inspected independently. > > .---------. > |Traffic | > .---->|Collector|<==>Customer#A > | |#1 | > | '---------' > RD=100:1 > .-----------. | > .--------. |IPFIX |----' .---------. > |IPFIX | |Distributor| RD=100:2 |Traffic | > |router#1|------->| |--------->|Collector|<==>Customer#B > | | | | |#2 | > '--------' | |----. '---------' > '-----------' | > RD=100:3 > | .---------. > | |Traffic | > '---->|Collector|<==>Customer#C > |#3 | > '---------' > > Figure A: Rerouting Flow Records to Collectors using IPFIX > Distributor > > 3.5. IPFIX Export from Branch Office > > > Generally, in big enterprise networks, traffic data from branch > offices is gathered in a central office. But, in the long distance > branch office case, the bandwidth for transport IPFIX is not enough. "sufficient" > > > > Kobayashi, et al. Expires March 30, 2009 [Page 10] > > Internet-Draft Mediation Problem Statement September 2008 > > > Therefore, it is beneficial that an IPFIX Concentrator located in a > branch office exports aggregated Flow Records to cope with the > limitation of bandwidth. > > 3.6. Correlation of Flow Records/Packet Reports Information > > > The correlation of Flow Records/Packet Reports information offers > some new metrics. There are some examples as follows: > > o One way delay follows from correlating Packet Reports exported > from different Exporters on the path. > > o The result of a queueing or rate-limiting function applied to "queuing" > ingress or egress interface follows from correlating Flow Records > with the same Flow Key observed at both interfaces. > > o Average/maximum/minimum values follow from correlating each in a > set of Flow Records. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 11] > > Internet-Draft Mediation Problem Statement September 2008 > > > 4. Approaches to Scalability > > > Usually, operators measure traffic at several Observation Points for > a specific purpose, typically sampling packets with rates ranging > from 1/10,000 to 1/100. This value depends on several factors, such > as the capacity of the management network, the available storage and > speed of the Collector, and the load on the routers/switches. > > On the one hand, the number of Observation Points in the networks can > even be increased to improve the effectiveness of these methods. In "is expected to increase in order to" > the near future, we anticipate that the advanced features of IPFIX, > such as the monitoring of wide-area traffic matrices and QoS > performance, will accelerate IPFIX utilization. > > On the other hand, the increasing amount of traffic brought about by > broadband users might have an impact on measurement parameters, such > as the sampling rate or granularity of Flows. Generally, large-scale > networks already have multiple 10 Gb/s links, their total traffic > exceeding 100 Gb/s. In the near future, broadband users' traffic > will increase by approximately 50% per year according to [TRAFGRW]. > When operators monitor traffic of 500 Gb/s with a sampling rate of > 1/1000, the amount of exported Flow Records from Exporters could > exceed 50 kFlows/s. This value is beyond the ability of a single > Collector. > > This section explains how operators can cope with such a huge amount > of Flow Records using available IPFIX solutions. Generally, the > solutions encompass two approaches: reducing the amount of exported > Flow Records or increasing the capacity of the Collecting Process. > The following sub-sections show each solution. > > 4.1. Adjusting Sampling Rates > > > Adjusting the sampling rate can reduce the amount of Flow Records, > and a flow-based measurement system can thus easily adapt to the > ability of the Collecting and Exporting Processes. However, in that > case, Flows with small traffic volumes could easily get lost. If > traffic incidents happened, operators would no longer be able to > investigate traffic change. While traffic volumes on networks "If traffic volumes ..." > continue to increase, operators will not be able to maintain the > sampling rates currently used. In the near future, flow-based > measurement systems possibly will not be able to detect traffic > anomalies which can currently be detected. > > 4.2. Flow Aggregation > > > The simplest types of Flows are those comprised of all packets having > a fixed five tuple of protocol, source and destination IP addresses, > > > > Kobayashi, et al. Expires March 30, 2009 [Page 12] > > Internet-Draft Mediation Problem Statement September 2008 > > > and source and destination port numbers. On the other hand, choosing > a shorter Flow Key, such as a three tuple or two tuple, or a single > Flow Key, such as a network prefix, peering AS number, or BGP Next- > Hop, creates more aggregated Flow Records. This solution is > especially useful for measurements of traffic exchange in an entire > network domain and for easy adjustments to the performance of a > Collector. > > 4.2.1. Flow Aggregation on Original Exporters > > > Original Exporters can aggregate Flow Records to reduce the amount of > them. But, in-depth traffic monitoring might not be possible, as it > is with the five tuple. One way to this is to be able to specify the > Template Records for specific needs. This extra flexibility in the If you want to adopt the terminology from IPFIX configuration, it's the Cache Layout that is configured (not the Template Record). In the vision of IPFIX configuration, the Template Record results from the Cache Layout, not the other way round. > Metering Process allows operators to specify their own set of Flow > Keys and extra Information Elements in the Template Record. > Specifically, Original Exporters classify the Flow Records by their > contents, and then aggregate them with appropriate Flow keys based on You assume one specific implementation where the Metering Process first produces IP-quintuple Flows which are then aggregated. However, it is also possible to directly generate Flows with Flow Key fields differing from the usual IP-quintuple. In this case, it is not an IPFIX Mediation function but just a Metering Process. Also, I would not call this case flow "aggregation". > a specific application. There is an application for security, The Exporter is not aware of any "application", it only functions according to its configuration. So, I would remove "based on a specific application". You might replace it by "based on a given configuration". > another for capacity planning, and so on. The content and > granularity of the Flow can satisfy the requirements of each > Collector with a specific application. > > On one hand, this optimizes the Metering Process, because only Flows > of interest are looked at. On the other hand, it optimizes the > Exporting Process, because only the information of interest is > exported. Finally, this reduces load of the Collecting Process as > less Flow Records are handled, and Flow Record filtering and > aggregating are required. Ok. So this subsection proposed a solution that works without IPFIX Mediation. > 4.2.2. Flow Aggregation on IPFIX Concentrators > > > Another approach involves a hierarchical measurement system using > IPFIX Concentrators. Aggregation and storage for input Flow Records RFC 3917: A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol. So, storing records is not a primary function of an IPFIX Concentrator as you write here. > on IPFIX Concentrators makes a most useful distributed-collection > system. It allows other devices to retrieve the stored Flow Record. > This method increases the capacity of Collecting Process of whole > system. Flow aggregation method is described in > [I-D.dressler-ipfix-aggregation] in detail. > > 4.3. Time Composition > > > Time composition is defined as aggregation for consecutive Flow > Records with same Flow Keys. It leads to the same output as setting rather: "with identical Flow Key values" > a longer active interval timer on Original Exporters. However, an > IPFIX Mediation can calculate average, maximum and minimum values of > each counter from Flow Records received with shorter interval time. > The output allows operators to keep track of changes that might have > > > > Kobayashi, et al. Expires March 30, 2009 [Page 13] > > Internet-Draft Mediation Problem Statement September 2008 > > > happened during the time interval. > > 4.4. Space Composition > > > Space composition is defined as aggregation for one or more Flow > Records involved in a larger Observation Domain or a set of > Observation Points. It is divided into two types: > > o Space Composition within one Exporter > > In that case, the spatial range is within one Exporters. For "Exporter" > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. I do not understand. > o Space Composition within some Exporters > > In that case, the spatial range consists of some different > Exporters. For example, the Flow Records observed at same domain, "in the same domain" > such as west area and east area of an ISP network, can be composed > to one Flow Records. > > 4.5. Distributing Load among Collectors > > > As described in the previous section, an IPFIX Distributor reroutes > Flow Records/Packet Reports to appropriate Collectors based on the > result of the Flow-based Collector Selection. It can thus distribute > the load among multiple Collectors according to a specific > application, each area, or each customer. > > 4.6. Flow Selection Sampling > > > A Flow selection sampling method is described in > [I-D.peluso-flowselection] in detail. Generally, the distribution of > the number of packets per Flow seems to be heavy-tailed. Most types > of Flow Records are likely to be small Flows consisting of a small > number of packets. The flow-based measurement system, in particular > the Collecting Process and Exporting Process, is burdened with a huge > amount of these small Flows. If statistics information of small > Flows is exported as merging data by applying a policy or threshold, "merged data"? > the burden on measurement system is reduced. > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 14] > > Internet-Draft Mediation Problem Statement September 2008 > > > 5. Problems with using IPFIX Mediators > > > In this section, we focus on the problems related to the use of IPFIX > Mediators in consideration of implementation. > > 5.1. Loss of Observation Point Information > > > Both the Exporter IP address indicated by the source IP address of > the IPFIX session as well as the Observation Domain ID included in > the IPFIX header are likely to be lost in the mediation process "IPFIX Message header" > performed by an IPFIX Mediator. This IP address and Observation > Domain ID indicate the Observation Point information from the > viewpoint of the entire network domain. Such information is > necessary for guaranteeing the continuity of the work of the top > level Collector. Even if an IPFIX Mediator could, with some new > mechanism, notify Collectors of this Observation Point information, > older Collectors might not accept it. These Collectors would then > wrongly assume that the IP address of the IPFIX Mediator is that of > the Original Exporter. The Collector, however, needs to recognize > the precise Observation Point whether Flow Records go through an > IPFIX Mediator or not. > > In the following figure, a Collector could identify 2 Exporters with > IP addresses of 10.1.1.3 and 10.1.1.2, respectively. The Collector, > however, needs to somehow recognize Router#1 and Router#2, which are > the Original Exporters. Defined notification methods that can be > interpreted by Collectors and Mediators are thus necessary. > > .--------. .--------. > |IPFIX | |IPFIX | > |Router#1|--------->|Mediator|---+ > | | | | | > '--------' '--------' | .---------. > IP:10.1.1.1 IP:10.1.1.3 '----->| | > ODID:10 ODID:0 |Collector| > +----->| | > .--------. | '---------' > |IPFIX | | > |Router#2|-----------------------' > | | > '--------' > IP:10.1.1.2 > ODID:20 > > Figure B: Loss of Observation Point Information. In some cases, e.g. masquerading, it might be desired to drop OD information ;) > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 15] > > Internet-Draft Mediation Problem Statement September 2008 > > > 5.2. Loss of Base Time Information > > > The Export Time field included in the IPFIX header indicates the base > time for Flow Records. In IPFIX Information Elements, described in > [RFC5102], there are delta time fields that indicate the time > difference from the value of the Export Time field. If the Flow > Records include any delta time fields and the IPFIX Mediator > overwrites the Export Time field when sending IPFIX messages, the > delta time fields become meaningless and, because Collectors can not > recognize this situation, wrong time values are propagated. In the described case, the delta time fields contain wrong values regardless of whether the Collector recognizes this situation or not! > > 5.3. Loss of Option Template Information > > > In some cases, depending on the implementation of the IPFIX > Mediators, the information that is reported by the Option Templates > could also be lost. If, for example, the sampling rate is not > communicated to the Collectors, a Collector would miscalculate the > traffic volume. This might bring crucial problems. Even if an IPFIX > Mediator were to simply relay received Option Template Information, "was to" > the value of its scope fields would become meaningless in the context "could become" > of a different session. It should be noted that the minimal > information to be communicated by an IPFIX Mediator needs to be > defined. remove "it should be noted that" > > 5.4. Observation Domain ID and Template ID Management > > > The Observation Domain ID is locally unique to the Exporting Process > in an IPFIX Mediator, just like the Template ID is unique on the > basis of the Observation Domain ID. These renewed identifiers should Be careful with repeating incomplete RFC5101 specs. Template IDs are unique per Transport Session! > be managed using the Transport Session Information of the Collecting > Process. If IPFIX Mediators could not manage the relations among "were not able to" > these identifiers and the received Transport Session Information, the > Mediators would, for example, relay wrong values for the scope fields > of the Option Template and for a "Template Withdraw Message". In You assume that the Template ID is in the Option's scope. That does not have to be the case. > most cases, a Collector would not be able to interpret the Template > ID of a "Template Withdraw Message" and the scope fields of an Option > Template. The Collector would then shut down the IPFIX Session. > > 5.5. Transport Sessions Management > > > How an IPFIX Mediator maintains relationships between the Transport > Sessions of Collecting Processes and of Exporting Processes depends > on its implementation. If multiple Transport Sessions of the > Collecting Process are relayed to single Transport Session of the > Exporting Process and the IPFIX Mediators shuts down the Transport > Session of the Exporting Process, Flow Records on other Transport > Sessions of the Collecting Processes would not be relayed at all. In > the case of resetting a session of the Collecting Process, the I do not see a problem here. Outgoing transport session and incoming transport sessions should be independent and configurable. There is no automatism to shut down an outgoing session because an incoming session closes. > > > > Kobayashi, et al. Expires March 30, 2009 [Page 16] > > Internet-Draft Mediation Problem Statement September 2008 > > > behavior of the IPFIX Mediator needs to be defined. > > > .--------. > |IPFIX | > |Router#1|----+ > | | | > '--------' X > .--------. | .--------. .---------. > |IPFIX | '---->|IPFIX | | | > |Router#2|--------->|Mediator|----X---->|Collector| > | | +---->| | | | > '--------' | '--------' '---------' > .--------. | > |IPFIX | | > |Router#3|----' > | | > '--------' > > Figure C: Relaying from Multiple Transport Sessions to Single > Transport Session. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 17] > > Internet-Draft Mediation Problem Statement September 2008 > > > 6. Conclusion > > > This document has covered the applicability of IPFIX Mediation and a > multitude of problems related to the implementation of IPFIX > Mediators. To assist the ability of the Exporters and Collectors, it > should be noted that there are various IPFIX Mediation functions for > the operators to select from. Examples of the applicability of IPFIX > Mediation are as follows. > > o Regarding IPFIX Exporting across domains, IPFIX Masquerading > Proxies help operators to anonymize or filter Flow Records/Packet > Reports, preventing privacy violations. > > o Regarding data retention, IPFIX Mediators enhance the storage of > the measurement system. > > o Regarding interoperability, IPFIX Proxies provide interoperability > between legacy protocols and IPFIX, even during the migration > period to IPFIX. > > o Regarding the Flow-based Collector Selection function, in > integrated networks, which mix MPLS VPN and IPv4/IPv6, this could > be utilized more frequently. More sophisticated implementation > methods would enhance the effectiveness. > > o Regarding scalability in large-scale networks, IPFIX Concentrators > or IPFIX Distributors help to achieve high sample rates and fine- > grained Flow analysis even as networks grow. As IPFIX Mediation > functions, Flow selection sampling, aggregation and composition > are beneficial. > > As a result, the benefits of IPFIX Mediation become apparent. > However, there are still some open issues. > > o With the use of IPFIX Mediators, both Observation Point and IPFIX > header information, such as the Exporter IP address, Observation > Domain ID, and Export Time field, might be lost. This data should > therefore be communicated between the Original Exporter and > Collector via the IPFIX Mediator. > > o With the use of IPFIX Mediators, data advertised by Option > Templates from the Original Exporter, such as the sampling rate > and sampling algorithm used, might be lost. If a Collector is not > informed of current sampling rates, traffic information might > become worthless. > > o IPFIX Mediators are required to manage Transport Sessions, > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > > > Kobayashi, et al. Expires March 30, 2009 [Page 18] > > Internet-Draft Mediation Problem Statement September 2008 > > > IPFIX messages could be created. > > These problems stem from the fact that no standards regarding IPFIX > Mediation have been set. In particular, the minimum set of > information which should be communicated between Original Exporters > and Collectors, interworking between different IPFIX Transport > Sessions, and the internal components of IPFIX Mediators should be > standardized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 19] > > Internet-Draft Mediation Problem Statement September 2008 > > > 7. Security Considerations > > > A flow-based measurement system might lead to privacy violations, > such as the export of Flow Records to an outside address, if the > system is not confined to the large-scale network under observation. > General security issues of the IPFIX protocol are covered by the > security considerations section in [RFC5101]. Security MUST be > considered if different networks exchange Flow information. As the > security of the exchange relies mostly on the protocol used, UDP does > not seem appropriate for the exchange of information between > networks. > --------------ms030702030500070303080007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzExMDkwMVowIwYJKoZIhvcNAQkEMRYEFCb7GFEvNpUs YmPpiegjDPNp9uKVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCBzaYi4z6lWL1F98DQPHKvLYt9qFU9oHRDbemkCQZgA45R/nXceGc3FLW8 ZP+7pF++wrlv/Lt9bWu/vmFLDZQrJya85WIoMOulECQ4lCFLxOsI/yt1Pg+I4YD1KzlDKnwc SbhQ0bFTxKiRonaaZUBKzgsaP0F8awO5dZIRl4AJ+ZP64HB04Y4uQjQGy+GtHKL8LlVHf6TM i8jwQcGGJgR0GR9BaMYvjl8PdR4E8KaBanR6Why/FnAQuw9oqCZsnDfd3D4TFZLUEU/W4ZAj 7m3B5pKGY6dyuqhbKXBbHq/PWpCbUxBRADpvpT+Z5NfE4uwJ1zcSzN8FSWLCpECZ3v5bAAAA AAAA --------------ms030702030500070303080007-- --===============1458089146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1458089146==-- From ipfix-bounces@ietf.org Mon Nov 17 03:09:03 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468963A6768; Mon, 17 Nov 2008 03:09:03 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FC023A6768 for ; Mon, 17 Nov 2008 03:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBCBWE4ogBDV for ; Mon, 17 Nov 2008 03:08:59 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id BA4503A6403 for ; Mon, 17 Nov 2008 03:08:58 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id AE4CE47B59 for ; Mon, 17 Nov 2008 12:08:53 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 9547B48C1 for ; Mon, 17 Nov 2008 12:08:53 +0100 (CET) Message-ID: <492150CD.4040101@net.in.tum.de> Date: Mon, 17 Nov 2008 12:09:01 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1458089146==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1458089146== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030702030500070303080007" This is a cryptographically signed message in MIME format. --------------ms030702030500070303080007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Atsushi, all, I reviewed the mediator problem statement draft. For me, the purpose of the draft is not quite clear. Is it to justify the need of IPFIX Mediators? Then, the focus should be more on monitoring situations that cannot be adequately handled without this intermediate box between exporters and collectors. If functionalities like configurable flow keys, flow selection, anonymization are realized on an IPFIX exporter directly, they can be considered as part of the Metering Process. So, there is no mediation involved. Therefore, I would restrict the usage of the term "mediation" to the IPFIX mediator case. Regards, Gerhard > Abstract > > Flow-based measurement is currently a popular method for various Remove "currently". We should assume that this is also valid in future. > network monitoring usages. The sharing of flow-based information > among orthogonal monitoring applications raises open issues in terms not sure what you mean by "orthogonal" > of scalability, reliability and flexibility that IPFIX Mediation may > help resolve. IPFIX Mediation reroutes, replicates, filters, > aggregates, correlates or modifies Flow Records or Packet Reports, or > changes a transport protocol. This document describes the You could introduce more clearly two classes of mediation: - mediation of content which changes the information, e.g. sampling, filtering, aggregation, anonymization,... - mediation of IPFIX transport which does not affect the information, e.g. rerouting, replication, changing the transport protocol etc. (storage would also fall into this category) > applicability of IPFIX Mediation and the problems that IPFIX > Mediation might encounter. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology and Definition . . . . . . . . . . . . . . . . . . 4 > 3. Flow-Based Mediation: Applicability Examples . . . . . . . . . 9 > 3.1. IPFIX Export Across Domains . . . . . . . . . . . . . . . 9 > 3.2. Data Retention . . . . . . . . . . . . . . . . . . . . . . 9 > 3.3. Interoperability between Legacy Protocols and IPFIX . . . 9 > 3.4. Rerouting Flow Records/Packet Reports . . . . . . . . . . 10 > 3.5. IPFIX Export from Branch Office . . . . . . . . . . . . . 10 > 3.6. Correlation of Flow Records/Packet Reports Information . . 11 > 4. Approaches to Scalability . . . . . . . . . . . . . . . . . . 12 > 4.1. Adjusting Sampling Rates . . . . . . . . . . . . . . . . . 12 > 4.2. Flow Aggregation . . . . . . . . . . . . . . . . . . . . . 12 > 4.2.1. Flow Aggregation on Original Exporters . . . . . . . . 13 > 4.2.2. Flow Aggregation on IPFIX Concentrators . . . . . . . 13 > 4.3. Time Composition . . . . . . . . . . . . . . . . . . . . . 13 > 4.4. Space Composition . . . . . . . . . . . . . . . . . . . . 14 > 4.5. Distributing Load among Collectors . . . . . . . . . . . . 14 > 4.6. Flow Selection Sampling . . . . . . . . . . . . . . . . . 14 > 5. Problems with using IPFIX Mediators . . . . . . . . . . . . . 15 > 5.1. Loss of Observation Point Information . . . . . . . . . . 15 > 5.2. Loss of Base Time Information . . . . . . . . . . . . . . 16 > 5.3. Loss of Option Template Information . . . . . . . . . . . 16 > 5.4. Observation Domain ID and Template ID Management . . . . . 16 > 5.5. Transport Sessions Management . . . . . . . . . . . . . . 16 > 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 > Intellectual Property and Copyright Statements . . . . . . . . . . 25 > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 2] > > Internet-Draft Mediation Problem Statement September 2008 > > > 1. Introduction > > > While the IPFIX requirements defined in [RFC3917] mention an > intermediate function, such as an IPFIX Proxy or an Concentrator, "...mention intermediate functions, such as IPFIX proxies and IPFIX concentrators [not sure if these terms should start with capital letters],..." > there is no document to define the function called IPFIX Mediation. > IPFIX Mediation is an additional function to suit the needs of some > measurement system. In this document, we describe several applicable Isn't IPFIX Mediation supposed to be an umbrella term which includes IPFIX concentrators and IPFIX proxies? > examples of IPFIX Mediation. Furthermore, we describe the problems > of IPFIX Mediation considering implementations. These problems can > be solved by additional specifications without influencing the > present IPFIX specification defined in [RFC5101]. "IPFIX protocol specification" > Section 2 describes the terminology used in this document. Section 3 > describes applicable examples of IPFIX Mediation. As more effective > cases, section 4 describes some usages of the IPFIX Mediation in > large-scale networks. Finally, section 5 describes the problems an > implementation of an IPFIX Mediation device might face. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 3] > > Internet-Draft Mediation Problem Statement September 2008 > > > 2. Terminology and Definition > > > The terms in this section are in line with those in the IPFIX > specification document [RFC5101] and the PSAMP specification document > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX What do you mean by "inline"? If you reuse terms from RFC5101, then you do not have to repeat them here. Only additional terms should appear in this section. Otherwise it is not clear which terms are new. > Mediation are also defined here. All these terms are capitalized in > this document. > > Observation Point > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. > > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Point > may be a superset of several other Observation Points. For > example, one Observation Point can be an entire line card. That > would be the superset of the individual Observation Points at the > line card's interfaces. > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IPFIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain IDs > also be unique per IPFIX Device. > > Flow Key > > Each of the fields that: > > 1. belong to the packet header (e.g., destination IP address), > > 2. are a property of the packet itself (e.g., packet length), > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > number), > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 4] > > Internet-Draft Mediation Problem Statement September 2008 > > > and that are used to define a Flow are termed Flow Keys. > > Flow Record > > A Flow Record contains information about a specific Flow that was > observed at an Observation Point. A Flow Record contains measured > properties of the Flow (e.g., the total number of bytes for all > the Flow's packets) and usually characteristic properties of the > Flow (e.g., source IP address). > > Packet Reports > > Packet Reports comprise a configurable subset of a packet's input > to the Selection Process, including the Packet Content, > information relating to its treatment (for example, the output > interface), and its associated selection state (for example, a > hash of the Packet Content). > > Exporting Process > > The Exporting Process sends Flow Records to one or more Collecting > Processes. The Flow Records are generated by one or more Metering > Processes. > > Exporter > > A device that hosts one or more Exporting Processes is termed an > Exporter. > > IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting Processes and arbitrary numbers of Observation > Points and Metering Processes. > > Collecting Process > > A Collecting Process receives Flow Records from one or more > Exporting Processes. The Collecting Process might process or > store received Flow Records, but such actions are out of scope for > this document. > > Collector > > A device that hosts one or more Collecting Processes is termed a > Collector. > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 5] > > Internet-Draft Mediation Problem Statement September 2008 > > > IPFIX Message > > An IPFIX Message is a message originating at the Exporting Process > that carries the IPFIX records of this Exporting Process and whose > destination is a Collecting Process. An IPFIX Message is > encapsulated at the transport layer. > > Information Element > > An Information Element is a protocol and encoding-independent > description of an attribute that may appear in an IPFIX Record. > The IPFIX information model [RFC5102] defines the base set of > Information Elements for IPFIX. The type associated with an > Information Element indicates constraints on what it may contain > and also determines the valid encoding mechanisms for use in > IPFIX. > > IPFIX Mediation > > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in Isn't it located between a Collecting Process and an Exporting Process? CP => Mediation => EP > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: "IPFIX Mediation consists of one or multiple of the following functions:" > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process BTW: this is a proxy function, so mediation is an umbrella term (see above) > * replicating input Flow Records/Packet Reports Not clear for what purpose Records should be replicated. Maybe add "in order to ....". > * filtering and selecting input Flow Records/Packet Reports remove "input"? > * aggregating input Flow Records/Packet Reports based on new Flow > Keys "based on a new set of Flow Key fields"? > * correlating a set of Flow Records/Packet Reports for creating > new Flow Records/Packet Reports with new metrics > > * modifying input Flow Records/Packet Reports remove "input"? > * changing a transport protocol which carries IPFIX Messages "changing the transport protocol" > The modification of Flow Records/Packet Reports includes these > functions: > > * changing the value of specified Information Elements > > * adding new Information Elements by deriving further Flow or > packet properties from existing fields or calculating new > > > > Kobayashi, et al. Expires March 30, 2009 [Page 6] > > Internet-Draft Mediation Problem Statement September 2008 > > > metrics > > * deleting specified Information Elements. I would move these bullet points below "modifying Flow Records/Packet Reports" in the preceding list because at that time the reader already wonders what "modify" could mean. > > IPFIX Mediation can be included in any devices, such as routers, > switches, NMS(Network Management Systems), or be deployed in > stand-alone devices. I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX Mediators. If performed on the original exporter, we already do have the Metering Process which can do all these things. > > Flow-Based Collector Selection > > The Flow-Based Collector Selection evaluates an input Flow Record/ > Packet Report based on the value of the specified Information > Element and then selects Collector for each input Flow Record/ > Packet Report. "Flow-Based Collector Selection is an IPFIX Mediation function which selects a Collector for every Flow Record/Packet Report. The selection of a Collector is based on match filters applied to record fields identified by Information Elements." > IPFIX Mediator > > An IPFIX Mediator contains one or more functions defined in IPFIX "one or more IPFIX Mediation functions" > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > device. It also contains one or more Collecting Processes and one What do you mean by "virtual"? > or more Exporting Processes. > > Original Exporter > > An Original Exporter is an IPFIX Device which hosts Observation > Points where IP packets can be directly observed. "where the metered IP packets are observed" > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX Mediator? Sending to multiple Collectors requires "replication" of IPFIX Messages, which implies that the included records are replicated as well. You mention "replication" in the case of IPFIX Distributor below. Maybe you want to mention it here as well? > Collectors. It may alter a part of IPFIX Message in order to "a part of the" > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, "change the transport protocol" > and convert a legacy protocol message to an IPFIX Message, if > necessary. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > Records/Packet Reports, aggregates them, then exports the > aggregated Flow Records. > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > Records/Packet Reports based on the result of Flow-Based Collector > Selection. It may filter or replicate input Flow Records/Packet > > > > Kobayashi, et al. Expires March 30, 2009 [Page 7] > > Internet-Draft Mediation Problem Statement September 2008 > > > Reports, if necessary. What is the difference between IPFIX Proxy and IPFIX Distributor? Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX Distributor handles individual records? > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > configured policies. It can thus, for example, hide the network > topology information or customers' IP addresses. Note: If you call this a "proxy", then my above distinction between IPFIX Proxy and IPFIX Distributor does not work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 8] > > Internet-Draft Mediation Problem Statement September 2008 > > > 3. Flow-Based Mediation: Applicability Examples > > > 3.1. IPFIX Export Across Domains > > > IPFIX export across administrative domains can be used to measure > traffic for wide-area traffic engineering, or to analyze the trend of > Internet traffic. In such cases, operators need to adhere to privacy > policies and prevent the transmission of confidential information. "prevent the transmission of confidential information" is unclear. Rather: "prevent the access to confidential traffic measurements by other operators" > Using an IPFIX Masquerading Proxy allows them to operate on Flow > Records safely by anonymizing and filtering them. IP Flow Who operates on the Flow Records? Anonymization rather makes it possible to give the Flow Records away to other operators without violating privacy policies. > anonymisation is described in [I-D.boschi-ipfix-anon] in detail. > > 3.2. Data Retention > > > Data retention refers to the storage of traffic data by service > providers and commercial organizations. According to European > Commission directives, operators are required to retain both IP and > voice traffic data, in wired and wireless networks, generated by end > users while using a service provider's services. The goal of data > retention is to ensure that call detail records and Flow Records are > available for the purpose of detection, investigation, and > prosecution of serious crimes, if necessary. The European Commission > directives define the following data retention services: > > o Fixed telephony (includes fixed voice, voicemail, and conference > and data calls) > > o Mobile telephony (includes mobile voice, voicemail, conference and > data calls, SMS, and MMS) > > o Internet telephony (includes every multimedia session associated > with IP multimedia services) > > o Internet e-mail > > o Internet access > > By monitoring Flow Records, IPFIX can fulfill these requirements of > Internet access services. Ok, but where is the link to IPFIX Mediation? > 3.3. Interoperability between Legacy Protocols and IPFIX > > > During the migration process from a legacy protocol such as NetFlow > [RFC3954] to IPFIX, both NetFlow and IPFIX Exporters will need to co- "are likely to coexist" > exist in the same network. An IPFIX Proxy which converts a legacy > protocol to IPFIX will allow operators to continue measuring Flows > from legacy Exporters, even after introducing IPFIX Collectors. > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 9] > > Internet-Draft Mediation Problem Statement September 2008 > > > 3.4. Rerouting Flow Records/Packet Reports > > > Recently, several networks seem to have shifted towards integrated remove "seem to" > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to "...of different networks need to..." > be analyzed separately and from different perspectives. However, > handling them separately without improving the capability of the > Collector is difficult. An IPFIX Distributor rerouting Flow Records/ > Packet Reports based on the result of Flow-based Collector Selection, > would be necessary. Thus, it allows individual Collectors related to "An IPFIX Distributor allows separating and rerouting Flow Records/Packet Reports from different networks to different Collectors based on Flow-based Collector Selection." > each network to analyze traffic data for their own specific purposes. > > As another example, in case of rerouting specific customer's Flow > Records, an IPFIX Distributor needs to identify each customer. As it rather needs to identify the customer networks > identification data, the RD (Route Distinguisher), ingress IF, What is "IF"? > peering AS number, or BGP next hop are listed. As shown in the Where are they listed? Proposed formulation: "RD (..), ingress interface, ....., may be evaluated to distinguish different customer networks." > following figure, the IPFIX Distributor reroutes Flow Records based remove "As shown" > on the RD value. This system allows each customer's traffic to be > inspected independently. > > .---------. > |Traffic | > .---->|Collector|<==>Customer#A > | |#1 | > | '---------' > RD=100:1 > .-----------. | > .--------. |IPFIX |----' .---------. > |IPFIX | |Distributor| RD=100:2 |Traffic | > |router#1|------->| |--------->|Collector|<==>Customer#B > | | | | |#2 | > '--------' | |----. '---------' > '-----------' | > RD=100:3 > | .---------. > | |Traffic | > '---->|Collector|<==>Customer#C > |#3 | > '---------' > > Figure A: Rerouting Flow Records to Collectors using IPFIX > Distributor > > 3.5. IPFIX Export from Branch Office > > > Generally, in big enterprise networks, traffic data from branch > offices is gathered in a central office. But, in the long distance > branch office case, the bandwidth for transport IPFIX is not enough. "sufficient" > > > > Kobayashi, et al. Expires March 30, 2009 [Page 10] > > Internet-Draft Mediation Problem Statement September 2008 > > > Therefore, it is beneficial that an IPFIX Concentrator located in a > branch office exports aggregated Flow Records to cope with the > limitation of bandwidth. > > 3.6. Correlation of Flow Records/Packet Reports Information > > > The correlation of Flow Records/Packet Reports information offers > some new metrics. There are some examples as follows: > > o One way delay follows from correlating Packet Reports exported > from different Exporters on the path. > > o The result of a queueing or rate-limiting function applied to "queuing" > ingress or egress interface follows from correlating Flow Records > with the same Flow Key observed at both interfaces. > > o Average/maximum/minimum values follow from correlating each in a > set of Flow Records. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 11] > > Internet-Draft Mediation Problem Statement September 2008 > > > 4. Approaches to Scalability > > > Usually, operators measure traffic at several Observation Points for > a specific purpose, typically sampling packets with rates ranging > from 1/10,000 to 1/100. This value depends on several factors, such > as the capacity of the management network, the available storage and > speed of the Collector, and the load on the routers/switches. > > On the one hand, the number of Observation Points in the networks can > even be increased to improve the effectiveness of these methods. In "is expected to increase in order to" > the near future, we anticipate that the advanced features of IPFIX, > such as the monitoring of wide-area traffic matrices and QoS > performance, will accelerate IPFIX utilization. > > On the other hand, the increasing amount of traffic brought about by > broadband users might have an impact on measurement parameters, such > as the sampling rate or granularity of Flows. Generally, large-scale > networks already have multiple 10 Gb/s links, their total traffic > exceeding 100 Gb/s. In the near future, broadband users' traffic > will increase by approximately 50% per year according to [TRAFGRW]. > When operators monitor traffic of 500 Gb/s with a sampling rate of > 1/1000, the amount of exported Flow Records from Exporters could > exceed 50 kFlows/s. This value is beyond the ability of a single > Collector. > > This section explains how operators can cope with such a huge amount > of Flow Records using available IPFIX solutions. Generally, the > solutions encompass two approaches: reducing the amount of exported > Flow Records or increasing the capacity of the Collecting Process. > The following sub-sections show each solution. > > 4.1. Adjusting Sampling Rates > > > Adjusting the sampling rate can reduce the amount of Flow Records, > and a flow-based measurement system can thus easily adapt to the > ability of the Collecting and Exporting Processes. However, in that > case, Flows with small traffic volumes could easily get lost. If > traffic incidents happened, operators would no longer be able to > investigate traffic change. While traffic volumes on networks "If traffic volumes ..." > continue to increase, operators will not be able to maintain the > sampling rates currently used. In the near future, flow-based > measurement systems possibly will not be able to detect traffic > anomalies which can currently be detected. > > 4.2. Flow Aggregation > > > The simplest types of Flows are those comprised of all packets having > a fixed five tuple of protocol, source and destination IP addresses, > > > > Kobayashi, et al. Expires March 30, 2009 [Page 12] > > Internet-Draft Mediation Problem Statement September 2008 > > > and source and destination port numbers. On the other hand, choosing > a shorter Flow Key, such as a three tuple or two tuple, or a single > Flow Key, such as a network prefix, peering AS number, or BGP Next- > Hop, creates more aggregated Flow Records. This solution is > especially useful for measurements of traffic exchange in an entire > network domain and for easy adjustments to the performance of a > Collector. > > 4.2.1. Flow Aggregation on Original Exporters > > > Original Exporters can aggregate Flow Records to reduce the amount of > them. But, in-depth traffic monitoring might not be possible, as it > is with the five tuple. One way to this is to be able to specify the > Template Records for specific needs. This extra flexibility in the If you want to adopt the terminology from IPFIX configuration, it's the Cache Layout that is configured (not the Template Record). In the vision of IPFIX configuration, the Template Record results from the Cache Layout, not the other way round. > Metering Process allows operators to specify their own set of Flow > Keys and extra Information Elements in the Template Record. > Specifically, Original Exporters classify the Flow Records by their > contents, and then aggregate them with appropriate Flow keys based on You assume one specific implementation where the Metering Process first produces IP-quintuple Flows which are then aggregated. However, it is also possible to directly generate Flows with Flow Key fields differing from the usual IP-quintuple. In this case, it is not an IPFIX Mediation function but just a Metering Process. Also, I would not call this case flow "aggregation". > a specific application. There is an application for security, The Exporter is not aware of any "application", it only functions according to its configuration. So, I would remove "based on a specific application". You might replace it by "based on a given configuration". > another for capacity planning, and so on. The content and > granularity of the Flow can satisfy the requirements of each > Collector with a specific application. > > On one hand, this optimizes the Metering Process, because only Flows > of interest are looked at. On the other hand, it optimizes the > Exporting Process, because only the information of interest is > exported. Finally, this reduces load of the Collecting Process as > less Flow Records are handled, and Flow Record filtering and > aggregating are required. Ok. So this subsection proposed a solution that works without IPFIX Mediation. > 4.2.2. Flow Aggregation on IPFIX Concentrators > > > Another approach involves a hierarchical measurement system using > IPFIX Concentrators. Aggregation and storage for input Flow Records RFC 3917: A concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol. So, storing records is not a primary function of an IPFIX Concentrator as you write here. > on IPFIX Concentrators makes a most useful distributed-collection > system. It allows other devices to retrieve the stored Flow Record. > This method increases the capacity of Collecting Process of whole > system. Flow aggregation method is described in > [I-D.dressler-ipfix-aggregation] in detail. > > 4.3. Time Composition > > > Time composition is defined as aggregation for consecutive Flow > Records with same Flow Keys. It leads to the same output as setting rather: "with identical Flow Key values" > a longer active interval timer on Original Exporters. However, an > IPFIX Mediation can calculate average, maximum and minimum values of > each counter from Flow Records received with shorter interval time. > The output allows operators to keep track of changes that might have > > > > Kobayashi, et al. Expires March 30, 2009 [Page 13] > > Internet-Draft Mediation Problem Statement September 2008 > > > happened during the time interval. > > 4.4. Space Composition > > > Space composition is defined as aggregation for one or more Flow > Records involved in a larger Observation Domain or a set of > Observation Points. It is divided into two types: > > o Space Composition within one Exporter > > In that case, the spatial range is within one Exporters. For "Exporter" > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. I do not understand. > o Space Composition within some Exporters > > In that case, the spatial range consists of some different > Exporters. For example, the Flow Records observed at same domain, "in the same domain" > such as west area and east area of an ISP network, can be composed > to one Flow Records. > > 4.5. Distributing Load among Collectors > > > As described in the previous section, an IPFIX Distributor reroutes > Flow Records/Packet Reports to appropriate Collectors based on the > result of the Flow-based Collector Selection. It can thus distribute > the load among multiple Collectors according to a specific > application, each area, or each customer. > > 4.6. Flow Selection Sampling > > > A Flow selection sampling method is described in > [I-D.peluso-flowselection] in detail. Generally, the distribution of > the number of packets per Flow seems to be heavy-tailed. Most types > of Flow Records are likely to be small Flows consisting of a small > number of packets. The flow-based measurement system, in particular > the Collecting Process and Exporting Process, is burdened with a huge > amount of these small Flows. If statistics information of small > Flows is exported as merging data by applying a policy or threshold, "merged data"? > the burden on measurement system is reduced. > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 14] > > Internet-Draft Mediation Problem Statement September 2008 > > > 5. Problems with using IPFIX Mediators > > > In this section, we focus on the problems related to the use of IPFIX > Mediators in consideration of implementation. > > 5.1. Loss of Observation Point Information > > > Both the Exporter IP address indicated by the source IP address of > the IPFIX session as well as the Observation Domain ID included in > the IPFIX header are likely to be lost in the mediation process "IPFIX Message header" > performed by an IPFIX Mediator. This IP address and Observation > Domain ID indicate the Observation Point information from the > viewpoint of the entire network domain. Such information is > necessary for guaranteeing the continuity of the work of the top > level Collector. Even if an IPFIX Mediator could, with some new > mechanism, notify Collectors of this Observation Point information, > older Collectors might not accept it. These Collectors would then > wrongly assume that the IP address of the IPFIX Mediator is that of > the Original Exporter. The Collector, however, needs to recognize > the precise Observation Point whether Flow Records go through an > IPFIX Mediator or not. > > In the following figure, a Collector could identify 2 Exporters with > IP addresses of 10.1.1.3 and 10.1.1.2, respectively. The Collector, > however, needs to somehow recognize Router#1 and Router#2, which are > the Original Exporters. Defined notification methods that can be > interpreted by Collectors and Mediators are thus necessary. > > .--------. .--------. > |IPFIX | |IPFIX | > |Router#1|--------->|Mediator|---+ > | | | | | > '--------' '--------' | .---------. > IP:10.1.1.1 IP:10.1.1.3 '----->| | > ODID:10 ODID:0 |Collector| > +----->| | > .--------. | '---------' > |IPFIX | | > |Router#2|-----------------------' > | | > '--------' > IP:10.1.1.2 > ODID:20 > > Figure B: Loss of Observation Point Information. In some cases, e.g. masquerading, it might be desired to drop OD information ;) > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 15] > > Internet-Draft Mediation Problem Statement September 2008 > > > 5.2. Loss of Base Time Information > > > The Export Time field included in the IPFIX header indicates the base > time for Flow Records. In IPFIX Information Elements, described in > [RFC5102], there are delta time fields that indicate the time > difference from the value of the Export Time field. If the Flow > Records include any delta time fields and the IPFIX Mediator > overwrites the Export Time field when sending IPFIX messages, the > delta time fields become meaningless and, because Collectors can not > recognize this situation, wrong time values are propagated. In the described case, the delta time fields contain wrong values regardless of whether the Collector recognizes this situation or not! > > 5.3. Loss of Option Template Information > > > In some cases, depending on the implementation of the IPFIX > Mediators, the information that is reported by the Option Templates > could also be lost. If, for example, the sampling rate is not > communicated to the Collectors, a Collector would miscalculate the > traffic volume. This might bring crucial problems. Even if an IPFIX > Mediator were to simply relay received Option Template Information, "was to" > the value of its scope fields would become meaningless in the context "could become" > of a different session. It should be noted that the minimal > information to be communicated by an IPFIX Mediator needs to be > defined. remove "it should be noted that" > > 5.4. Observation Domain ID and Template ID Management > > > The Observation Domain ID is locally unique to the Exporting Process > in an IPFIX Mediator, just like the Template ID is unique on the > basis of the Observation Domain ID. These renewed identifiers should Be careful with repeating incomplete RFC5101 specs. Template IDs are unique per Transport Session! > be managed using the Transport Session Information of the Collecting > Process. If IPFIX Mediators could not manage the relations among "were not able to" > these identifiers and the received Transport Session Information, the > Mediators would, for example, relay wrong values for the scope fields > of the Option Template and for a "Template Withdraw Message". In You assume that the Template ID is in the Option's scope. That does not have to be the case. > most cases, a Collector would not be able to interpret the Template > ID of a "Template Withdraw Message" and the scope fields of an Option > Template. The Collector would then shut down the IPFIX Session. > > 5.5. Transport Sessions Management > > > How an IPFIX Mediator maintains relationships between the Transport > Sessions of Collecting Processes and of Exporting Processes depends > on its implementation. If multiple Transport Sessions of the > Collecting Process are relayed to single Transport Session of the > Exporting Process and the IPFIX Mediators shuts down the Transport > Session of the Exporting Process, Flow Records on other Transport > Sessions of the Collecting Processes would not be relayed at all. In > the case of resetting a session of the Collecting Process, the I do not see a problem here. Outgoing transport session and incoming transport sessions should be independent and configurable. There is no automatism to shut down an outgoing session because an incoming session closes. > > > > Kobayashi, et al. Expires March 30, 2009 [Page 16] > > Internet-Draft Mediation Problem Statement September 2008 > > > behavior of the IPFIX Mediator needs to be defined. > > > .--------. > |IPFIX | > |Router#1|----+ > | | | > '--------' X > .--------. | .--------. .---------. > |IPFIX | '---->|IPFIX | | | > |Router#2|--------->|Mediator|----X---->|Collector| > | | +---->| | | | > '--------' | '--------' '---------' > .--------. | > |IPFIX | | > |Router#3|----' > | | > '--------' > > Figure C: Relaying from Multiple Transport Sessions to Single > Transport Session. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 17] > > Internet-Draft Mediation Problem Statement September 2008 > > > 6. Conclusion > > > This document has covered the applicability of IPFIX Mediation and a > multitude of problems related to the implementation of IPFIX > Mediators. To assist the ability of the Exporters and Collectors, it > should be noted that there are various IPFIX Mediation functions for > the operators to select from. Examples of the applicability of IPFIX > Mediation are as follows. > > o Regarding IPFIX Exporting across domains, IPFIX Masquerading > Proxies help operators to anonymize or filter Flow Records/Packet > Reports, preventing privacy violations. > > o Regarding data retention, IPFIX Mediators enhance the storage of > the measurement system. > > o Regarding interoperability, IPFIX Proxies provide interoperability > between legacy protocols and IPFIX, even during the migration > period to IPFIX. > > o Regarding the Flow-based Collector Selection function, in > integrated networks, which mix MPLS VPN and IPv4/IPv6, this could > be utilized more frequently. More sophisticated implementation > methods would enhance the effectiveness. > > o Regarding scalability in large-scale networks, IPFIX Concentrators > or IPFIX Distributors help to achieve high sample rates and fine- > grained Flow analysis even as networks grow. As IPFIX Mediation > functions, Flow selection sampling, aggregation and composition > are beneficial. > > As a result, the benefits of IPFIX Mediation become apparent. > However, there are still some open issues. > > o With the use of IPFIX Mediators, both Observation Point and IPFIX > header information, such as the Exporter IP address, Observation > Domain ID, and Export Time field, might be lost. This data should > therefore be communicated between the Original Exporter and > Collector via the IPFIX Mediator. > > o With the use of IPFIX Mediators, data advertised by Option > Templates from the Original Exporter, such as the sampling rate > and sampling algorithm used, might be lost. If a Collector is not > informed of current sampling rates, traffic information might > become worthless. > > o IPFIX Mediators are required to manage Transport Sessions, > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > > > Kobayashi, et al. Expires March 30, 2009 [Page 18] > > Internet-Draft Mediation Problem Statement September 2008 > > > IPFIX messages could be created. > > These problems stem from the fact that no standards regarding IPFIX > Mediation have been set. In particular, the minimum set of > information which should be communicated between Original Exporters > and Collectors, interworking between different IPFIX Transport > Sessions, and the internal components of IPFIX Mediators should be > standardized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 19] > > Internet-Draft Mediation Problem Statement September 2008 > > > 7. Security Considerations > > > A flow-based measurement system might lead to privacy violations, > such as the export of Flow Records to an outside address, if the > system is not confined to the large-scale network under observation. > General security issues of the IPFIX protocol are covered by the > security considerations section in [RFC5101]. Security MUST be > considered if different networks exchange Flow information. As the > security of the exchange relies mostly on the protocol used, UDP does > not seem appropriate for the exchange of information between > networks. > --------------ms030702030500070303080007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzExMDkwMVowIwYJKoZIhvcNAQkEMRYEFCb7GFEvNpUs YmPpiegjDPNp9uKVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQCBzaYi4z6lWL1F98DQPHKvLYt9qFU9oHRDbemkCQZgA45R/nXceGc3FLW8 ZP+7pF++wrlv/Lt9bWu/vmFLDZQrJya85WIoMOulECQ4lCFLxOsI/yt1Pg+I4YD1KzlDKnwc SbhQ0bFTxKiRonaaZUBKzgsaP0F8awO5dZIRl4AJ+ZP64HB04Y4uQjQGy+GtHKL8LlVHf6TM i8jwQcGGJgR0GR9BaMYvjl8PdR4E8KaBanR6Why/FnAQuw9oqCZsnDfd3D4TFZLUEU/W4ZAj 7m3B5pKGY6dyuqhbKXBbHq/PWpCbUxBRADpvpT+Z5NfE4uwJ1zcSzN8FSWLCpECZ3v5bAAAA AAAA --------------ms030702030500070303080007-- --===============1458089146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1458089146==-- From ipfix-bounces@ietf.org Mon Nov 17 05:22:19 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3D53A68B4; Mon, 17 Nov 2008 05:22:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42713A689D for ; Mon, 17 Nov 2008 05:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGmVzW-KE0-a for ; Mon, 17 Nov 2008 05:22:14 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id BD7A83A688B for ; Mon, 17 Nov 2008 05:22:13 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 740BA47B59 for ; Mon, 17 Nov 2008 14:22:11 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 63CC192D for ; Mon, 17 Nov 2008 14:22:11 +0100 (CET) Message-ID: <4921700B.1040602@net.in.tum.de> Date: Mon, 17 Nov 2008 14:22:19 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0915081849==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0915081849== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090403090306060403050005" This is a cryptographically signed message in MIME format. --------------ms090403090306060403050005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Atsushi, all, I reviewed the mediator framework draft. In my opinion, it already is in a very good shape. The scope is clear and the description of the different mediator functions is comprehensive. I'm not sure about the "Flow-based Collector Selection". It does not seem to be a new function but rather a use-case of the "Flow Selection Function" (plus Exporting Process, see comments below). Probably, you should not reference future drafts that are supposed to provide technical solutions (such as IPFIX anonymization and aggregation drafts) because we do not know how the solutions will look like. RFC3917 does not reference any early IPFIX protocol draft, either. Some more examples for specific mediator use-cases might be useful. Regards, Gerhard > IPFIX Working Group A. Kobayashi > Internet-Draft H. Nishida > Intended status: Informational NTT PF Lab. > Expires: May 8, 2009 B. Claise > Cisco Systems > November 4, 2008 > > > > IPFIX Mediation: Framework > > > draft-ietf-ipfix-mediators-framework-01 > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > 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." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 8, 2009. > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 1] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Abstract > > This document describes a framework for an IPFIX Mediation. This "for an IPFIX Mediator" or "for IPFIX Mediation" > framework details an IPFIX Mediation reference model and the > components of the IPFIX Mediation device (IPFIX Mediator). > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 9 > 4. IPFIX Mediation Functional and Logical Blocks . . . . . . . . 12 > 4.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 12 > 4.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 12 > 4.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 12 > 4.3.1. Flow Selection Function . . . . . . . . . . . . . . . 12 > 4.3.2. Flow-based Collector Selection Function . . . . . . . 13 > 4.3.3. Aggregation Function . . . . . . . . . . . . . . . . . 13 > 4.3.4. Correlation Function . . . . . . . . . . . . . . . . . 14 > 4.3.5. Modification Function . . . . . . . . . . . . . . . . 15 > 4.4. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 16 > 4.5. Flow Expiration . . . . . . . . . . . . . . . . . . . . . 17 > 4.6. Information Model . . . . . . . . . . . . . . . . . . . . 18 > 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 > Intellectual Property and Copyright Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 2] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 1. Introduction > > > IPFIX Mediation reroutes, replicates, filters, aggregates, > correlates, or modifies Flow Records/Packet Reports or changes a > transport protocol. This document describes the framework for IPFIX > Mediation. The motivation for the IPFIX Mediation standard comes > from the need for flow-based measurement system support for large- > scale networks, interdomain networks, and coexistence with > traditional Exporters as described in detail in > [I-D.ietf-ipfix-mediator-ps]. The standard specification requires a > definition of IPFIX Mediation and IPFIX Mediation device (IPFIX > Mediator). I would not introduce "IPFIX Mediation device" as a synonym for "IPFIX Mediator". > > This document is organized as follows. Section 2 describes > terminology related to IPFIX Mediation. Section 3 describes a high > level reference model. Section 4 details the components of the IPFIX > Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 3] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 2. Terminology > > > The terms in this section are in line with those in the IPFIX > specification document [RFC5101] and the PSAMP specification document > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX Terms from RFC5101 and psamp-protocol should not be repeated. > Mediation are also defined with those in the IPFIX Mediator problem > statement [I-D.ietf-ipfix-mediator-ps]. All these terms are > capitalized in this document. > > Observation Point > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. > > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Point > may be a superset of several other Observation Points. For > example, one Observation Point can be an entire line card. That > would be the superset of the individual Observation Points at the > line card's interfaces. > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IPFIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain IDs > also be unique per IPFIX Device. > > Flow Key > > Each of the fields that: > > 1. belong to the packet header (e.g., destination IP address), > > 2. are a property of the packet itself (e.g., packet length), > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > number), > > > > Kobayashi, et al. Expires May 8, 2009 [Page 4] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > and that are used to define a Flow are termed Flow Keys. > > Flow Record > > A Flow Record contains information about a specific Flow that was > observed at an Observation Point. A Flow Record contains measured > properties of the Flow (e.g., the total number of bytes for all > the Flow's packets) and usually characteristic properties of the > Flow (e.g., source IP address). > > Packet Reports > > Packet Reports comprise a configurable subset of a packet's input > to the Selection Process, including the Packet Content, > information relating to its treatment (for example, the output > interface), and its associated selection state (for example, a > hash of the Packet Content). > > Exporting Process > > The Exporting Process sends Flow Records to one or more Collecting > Processes. The Flow Records are generated by one or more Metering > Processes. > > Exporter > > A device that hosts one or more Exporting Processes is termed an > Exporter. > > IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting Processes and arbitrary numbers of Observation > Points and Metering Processes. > > Collecting Process > > A Collecting Process receives Flow Records from one or more > Exporting Processes. The Collecting Process might process or > store received Flow Records, but such actions are out of the scope > of this document. > > Collector > > A device that hosts one or more Collecting Processes is termed a > Collector. > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 5] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX Message > > An IPFIX Message is a message originating at the Exporting Process > that carries the IPFIX records of this Exporting Process and whose > destination is a Collecting Process. An IPFIX Message is > encapsulated at the transport layer. > > Information Element > > An Information Element is a protocol and encoding-independent > description of an attribute that may appear in an IPFIX Record. > The IPFIX information model [RFC5102] defines the base set of > Information Elements for IPFIX. The type associated with an > Information Element indicates constraints on what it may contain > and also determines the valid encoding mechanisms for use in > IPFIX. > > IPFIX Mediation > > An IPFIX Mediation is a generic term for functions doing something > for Flow Records, Packet Reports, and IPFIX Messages. IPFIX > Mediation is located in between components: Metering Processes, > Exporting Processes, Collecting Processes, and other applications. > IPFIX Mediation can be included in any IPFIX Devices. IPFIX > Mediation consists of a set of some of the following functions: > > * rerouting input Flow Records/Packet Reports to an appropriate > Collecting Process > > * replicating input Flow Records/Packet Reports > > * filtering and selecting input Flow Records/Packet Reports > > * aggregating input Flow Records/Packet Reports based on new Flow > Keys > > * correlating a set of Flow Records/Packet Reports for creating > new Flow Records/Packet Reports with new metrics > > * modifying input Flow Records/Packet Reports > > * changing transport protocols that carry IPFIX Messages > > The modification of Flow Records/Packet Reports includes these > processes: > > * changing the value of specified Information Elements > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 6] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > * adding new Information Elements by deriving further Flow or > packet properties from existing fields or calculating new > metrics > > * deleting specified Information Elements. > > IPFIX Mediation can be included in any device, such as routers, > switches, NMS (Network Management Systems), or stand-alone > devices. > > Flow-Based Collector Selection > > The Flow-Based Collector Selection evaluates an input Flow Record/ > Packet Report based on the value of the specified Information > Element and then selects a Collector for each input Flow Record/ > Packet Report. > > IPFIX Mediator > > An IPFIX Mediator contains one or more functions defined in IPFIX > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > device. It also contains one or more Collecting Processes and one > or more Exporting Processes. > > Original Exporter > > An Original Exporter is an IPFIX Device that hosts Observation > Points where IP packets can be directly observed. > > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter and sends IPFIX Messages to one or more > Collectors. It may alter part of an IPFIX Message to comply with > IPFIX Protocol specifications. It may also change the type of > transport protocol, such as UDP, TCP, SCTP, and PR-SCTP, and > convert a legacy protocol message to an IPFIX Message, if > necessary. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > Records/Packet Reports, aggregates them, then exports the > aggregated Flow Records. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 7] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > Records/Packet Reports based on the result of Flow-Based Collector > Selection. It may filter or replicate input Flow Records/Packet > Reports, if necessary. > > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data of input Flow Records/Packet Reports according > to configured policies. It can thus, for example, hide the > network topology information or customers' IP addresses. > > Intermediate Process > > An Intermediate Process in IPFIX Mediators can be considered as a > partial Metering Process taken from the Metering Process in > Original Exporters as described in [RFC3917]. I do not like the definition of IP as "partial MP". This creates confusion and makes it difficult to distinguish MPs and IPs. > > The Intermediate Process generates new sets of Data Records/Packet > Reports from input Data Records/Packet Reports. > > Mediator Observation Domain > > An IPFIX Mediator does not host the Observation Points and Why should we disallow IPFIX Mediators which also have native Observation Points? > Observation Domain. The Observation Domain ID in the IPFIX header > sent by the IPFIX Mediator also indicates the largest set of > Observation Points from the viewpoint of a Collector. However, This seems to be too generic. The ODID issued by the mediator should identify the set of ODs/OPs the exported records belong to. It does not always have to be the "largest set of OPs", it can be a subset. As an example, the Mediator may be configured not to merge records from different OPs at all. In this case, we can keep the old OIDs. Or it may be configured to merge records from a specific subset of OPs only. > this value does not indicate the physical entity of an Original > Exporter. > > Transport Session Information > > The Transport Session is specified in [RFC5101]. In SCTP, the > Transport Session Information is the SCTP association. In TCP and > UDP, the Transport Session Information corresponds to a 5-tuple > {Exporter IP address, Collector IP address, Exporter transport > port, Collector transport port, and transport protocol}. > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 8] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 3. IPFIX Mediation Reference Model > > > The figure below shows the high-level reference model for IPFIX > Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > the various possible scenarios that can exist in an IPFIX measurement > system. > > > +---------------------------+ +---------------------------+ > | Collector {l} | | Collector {k} | > |[*Application(s)] | |[*Application(s)] | > |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > |[Collecting Process(es)] |....|[Collecting Process(es)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ ^ > | | | | > | +------....----+ | > | | | > IPFIX (Flow Records / Packet Reports) > | | | > +----------------+----+-----+ +-------+-------------------+ > |IPFIX Mediator {j} | |IPFIX Mediator {n} | > |[*Applications(s)] | |[*Applications(s)] | > |[Exporting Process(es)] | |[Exporting Process(es)] | > |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > |[Collecting Process(es)] | |[Collecting Process(es)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ > | | | > | +------....-----+ > | | > IPFIX (Flow Records / Packet Reports) > | | > +----------------+----------+ +----+----------------------+ > |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > |[Exporting Process(es)] | |[Exporting Process(es)] | > |[Metering Process(es)] |....|[Metering Process(es)] | > |[Observation Point(s)] | |[Observation Point(s)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ ^ > | | | | > Packets coming in to Observation Points > > Figure A: Reference Model for IPFIX Mediation. > > The various functional components are indicated within brackets []. > The functional components within [*] are not part of > [I-D.ietf-ipfix-architecture]. Hm. Intermediate Process as well as IPFIX reader/writer are not part of ipfix-architecture either. BTW: IPFIX reader/writer are considered as special types of CPs and EPs. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 9] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > The figure below shows the basic IPFIX Mediator component model. The > IPFIX Mediator is formally defined to consist of one or more > Collecting Processes, zero or more Intermediate Processes, and one or > more Exporting Processes. Basically, IPFIX Mediator devices, i.e., > IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor, and IPFIX > Concentrator, described in [I-D.ietf-ipfix-mediator-ps], are composed > of these components. > > > IPFIX(Flow Records/Packet Reports) > ^ > ^ | > +------------------------|-|---------------------+ > | IPFIX Mediator | | | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Exporting Process (es) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Intermediate Process (es) (optional) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Collecting Process (es) |' | > | '----------------------^--------------------' | > +------------------------|-|---------------------+ > | > IPFIX(Flow Records/Packet Reports) > > Figure B: IPFIX Mediator Basic Component Model. > > An Original Exporter with a Mediation function is modeled as follows. > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 10] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX (Flow Records/Packet Reports) > ^ ^ > +---------------------------|-|------------------------+ > | Original Exporter | | | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Exporting Process(es) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Intermediate Process(es) |' | > | '---------^-----------------------^---------' | > | |Flow Record or | | > | | Packet Reports | | > | .------------+----------. .---------+-------------. | > | | Metering Process {i} |..| Metering Process {n} | | > | '------------^----------' '---------^-------------' | > | | | | > | .------------+----------. .---------+-------------. | > | | Observation Point {i} |..| Observation Point {n} | | > | '------------^----------' '---------^-------------' | > +--------------|-----------------------|---------------+ > | | > Packets coming in to Observation Points > > Figure C: Component Model for Original Exporter with Mediation. > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 11] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 4. IPFIX Mediation Functional and Logical Blocks > > > The section describes the details of each component and examples > applicable to that component for IPFIX Mediation and IPFIX Mediator. > > 4.1. Collecting Process > > > The Collecting Processes described in [RFC5101] receive Flow Records/ > Packet Reports with information relating to their treatment in the > Metering Process and Exporting Process in the Original Exporter, such > as sampling rate, IPFIX header information, and Transport Session > Information. The Collecting Processes forward the set of data to > multiple components: Intermediate Processes and Exporting Processes. > In other words, the processes may duplicate received Flow Records/ > Packet Reports and forward them to multiple components in sequence or > in parallel. > > 4.2. Exporting Process > > > The Exporting Processes described in [RFC5101] forward Flow Records/ better verb for "forward"? e.g. "transmit"? > Packet Reports to one or multiple Collectors. The processes manage > the reporting Template and make IPFIX Messages. > > 4.3. Intermediate Process > > > Intermediate Processes generate new sets of Flow Records/Packet > Reports from input Flow Records/Packet Reports with IPFIX header > information "Export Time" and "Observation Domain ID". The processes I would not call it "IPFIX header information" because there are no IPFIX Messages at the input of the Intermediate Process, only Records. Maybe "context information collected at the Collecting Process"? > host one of several functions defined below or a combination of them, > in any sequence or in any set. In the case of a combination, the > output of each function can be the input of other functions. The > following subsections show the details of each function. > > 4.3.1. Flow Selection Function > > > The Flow Selection function determines which input Flow Records/ > Packet Reports are selected by matching under a filtering policy and > then forwards them to the next processes or functions. The function > is similar to the Selection Process described in > [I-D.ietf-psamp-framework]. The function covers several selection > techniques, such as property match filtering and Flow selection, > which are described in [I-D.ietf-psamp-framework] and > [I-D.peluso-flowselection], respectively. In property match > filtering, if the value of a specified Information Element equals a > configured value, the function selects Flow Records/Packet Reports to > forward. > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 12] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 4.3.2. Flow-based Collector Selection Function > > > The Flow-based Collector Selection function determines to which > Collector input Flow Records/Packet Reports are exported. The > function may also determine the type of Transport Session. The This functional description conflicts with the Exporting Process. In my opinion, the Exporting Process holds the information about the Collectors, transport protocol etc. > function evaluates the value of a specified Information Element in > input Flow Records/Packet Reports and then selects the Collector. So, what is the difference between Flow-Based Colelctor Selection Function and Flow Selection Function plus Exporting Process? I'm not sure if Flow-based Collector Selection should be a function of its own. I would rather say that it describes a use-case of one or multiple Flow Selection Functions and Exporting Processes: +--> Flow Selector 1 -> EP 1 ----+ +--> Flow Selector 2 -> EP 2 > These selection criteria are similar to the property match filtering > in Mediator Selection Function. > > Applicable examples include exporting Flow Records/Packet Reports to > a dedicated Collector on the basis of customers or organizations > peering. The function classifies Flow Records/Packet Reports on the > basis of a peering AS number, as shown in the following figure. The > set of classified Flow Records/Packet Reports is exported to a > dedicated Collector on the basis of the peering AS number. > > .----------------------------. > | Intermediate Process | > | .----------------------. | > | | Flow-Based Collector | | > | | Selection Function | | > | | | | > | | Peering AS #10 | | > | | +-------------------+-+---> Collector #1 > | | | Peering AS #20 | | > Flow --+---+--+-------------------+-+---> Collector #2 > Records | | | Peering AS #30 | | > | | +-------------------+-+---> Collector #3 > | '----------------------' | > '----------------------------' > > Figure D: Exporting classified Flow Records to dedicated Collector. > > 4.3.3. Aggregation Function > > > The Aggregation function creates aggregated Flow Records from input > Flow Records/Packet Reports. The aggregation method is divided into > three types: > > Choosing Shorter Flow Key > > Choosing a shorter Flow Key than the Flow Key of input Flow A "shorter Flow Key" would be an IP address of 8 bits. That is not what you mean. You rather decrease the number of fields considered as Flow Keys. > Records, such as three, two, or a single Flow Key, can create more "Flow Key field" > aggregated Flow Records. The function gathers Flow Records/Packet > Reports within a given interval time and then distinguishes Flow > Records/Packet Reports that have common properties. If values of It sounds strange to distinguish records that have common properties. You rather want to merge them. > a given key field are the same, that means those Flow Records/ > > > > Kobayashi, et al. Expires May 8, 2009 [Page 13] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Packet Reports have common properties, and the function merges > them in accordance with aggregation rules described in > [I-D.dressler-ipfix-aggregation]. > > In addition, the function can create statistical data and > subsidiary information related to the aggregated Flow Records. > Examples include the number of input Flow Records/Packet Reports, > the given interval time, and a set of a new Flow Key. "a new set of Flow Keys" (a Flow Key is a single field!) > > Time Composition > > Time composition is defined as aggregation with the same Flow Key "identical Flow Key values" > for long-running Flows. The function may also compute Flow > Records statistics, such as average, maximum, and minimum value of > each counter. The statistics help to visualize the behavior of > traffic volume over a long time period. > > As another approach, the function collects Flow Records/Packet > Reports of a shorter time period from an Original Exporter, and > then computes these statistics. Even if output Flow Records of > the function indicate a general time period, the accuracy of the > minimum, maximum, and average value can be improved. Where is the difference to what you described in the preceding paragraph? > > Space Composition > > Space composition is defined as aggregation on a larger > Observation Domain or on a set of Observation Points. In that > case, a Flow key can be applied to other properties, such as What do you mean by "a Flow Key can be applied to "? > Exporter IP address and Observation Domain ID. > > In addition, a group identifier indicating a spatial Observation > Domain can also become a new Flow Key. For example, a group can > indicate an area on an ISP network, or a link aggregation > interface composd of physical interfaces. The group can also make > a relation to a set of values of specified Information Elements in > Flow Records by the configuring rule. After converting from the > values of specified Information Elements to the group identifier, > the function can create aggregated Flow Records by a general > aggregation process. > > 4.3.4. Correlation Function > > > The Correlation function creates new metrics from by evaluating the > correlation among sets of Flow Records/Packets Records. These sets > can be Flow Records gathered during a certain period, a pair of > consecutive Packet Reports, or Packet Reports exported by different > Exporters indicating the same packet. After offering new metrics, > the function outputs Flow Records with the new metrics field. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 14] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Applicable examples are as follows. > > o One way delay follows from correlating Packet Reports exported > from different Exporters on the path. > > o Packet interval time, or jitter, follows from correlating > consecutive Packet Reports exported from the same Exporter. > > o Difference values follow from correlating Flow Records observed at > ingress or egress interfaces. The values help to confirm the > result of a queueing or rate-limiting function. > > o Average/maximum/minimum values follow from correlating each in a > set of Flow Records. > > 4.3.5. Modification Function > > > The Modification function modifies input Flow Records/Packet Reports > without changing their granularity. The function can add new > Information Elements, delete existing Information Elements, or modify > the value of specified Information Elements. If the function > modifies the data structure of an original Template, it also needs to > modify the value of the "flowKeyIndicator". > > Adding specified Information Elements > > The function obtains the value of a specified Information Element > and then adds it into Flow Records/Packet Reports. There are > several methods to obtain the value: retrieving the value from a > database or calculating the value based on the value of other > Information Elements and received traffic data. > > Applicable examples include adding derived packet property > parameters instead of Original Exporters. Doing that can remove "instead of Original Exporters" > compensate for traditional Exporters or probes unable to add > packet property parameters. Therefore, Collectors do not need to > recognize the difference among implementations of routers from > several vendors or among Exporter types, such as router, switch, > or probe. Typical derived packet property parameters include the > following. > > * The "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] > indicates the egress router of a network domain. That is > useful for making a traffic matrix that covers the whole > network domain. > > * The BGP Community value indicates the same group of destination > or source IP addresses. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 15] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > * The "mplsVpnRouteDistinguisher" described in [RFC5102], which > cannot be extracted from the core router in MPLS networks, > indicates the VPN customer's identification. Network operators > can monitor the traffic behavior of each customer by adding > "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports. > > Deleting specified Information Elements > > This function deletes existing Information Elements according to > instruction rules, which indicate whether an Information Element > should be removed. > > Applicable examples include hiding network topology information > and private information. In the case of IPFIX exporting across > domains, the function can avoid making a vulnerability by deleting > unnecessary Information Elements. Examples of network topology > information include "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4| > v6}Address", and "bgp{Next|Prev}AdjacentAsNumber", described in > [RFC5102]. In addition, MPLS-related Information Elements, such > as "mplsLabelStackSection", are useless for customers in the case > of feeding Flow Records/Packet Reports to VPN customers. > > Modifying the value of specified Information Elements > > This function modifies the value of specified Information > Elements. > > Applicable examples include anonymizing customers' private > information, such as IP address and port number, according to a > privacy protection policy. Several annonymization techniques are > described in [I-D.boschi-ipfix-anon]. The function also reports > anonymization methods and part of anonymized data as subsidiary > information. > > 4.4. IPFIX File Writer/Reader > > > The IPFIX File Writer stores input Flow Records/Packet Reports from > any process in a storage system. If received Flow Records/Packet It's a "file system". > Reports include uninteresting Information Elements, the Modification > Function can delete these elements before the IPFIX File Writer > handles them. Therefore, IPFIX File Writers can accept input from > any process. In either case, input needs to include the IPFIX header Remove the whole sentence "Therefore,..." > information and the Transport Session Information along with Flow > Records/Packet Reports. Why does the File Writer require header information and transport session information as input? We should not specify additional restrictions for the File Writer here. Also, there are cases where there are no headers and no transport sessions, e.g. if the writer is linked to a Metering Process. > > In contrast, the IPFIX File Reader retrieves stored Flow Records/ > Packet Reports when operators want to retrieve past Flow Records/ > Packet Reports on the basis of a given time period. If the data > > > > Kobayashi, et al. Expires May 8, 2009 [Page 16] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > structure of output Flow Records/Packet Reports from the IPFIX File > Reader is different from what operators want, the Modification > function can modify the data structure. Therefore, the output of > IPFIX File Readers can be input to any components. The IPFIX File > Writer/Reader are described in [I-D.ietf-ipfix-file] in detail. > > The figure shows the IPFIX component model with IPFIX File Writer/ > Reader. IPFIX File Writer/Reader are located in the same position of > Exporting Process/Collecting Process, respectively. According to ipfix-file, IPFIX File Writer/Reader operate as EP/CP. So, "located in the same position of EP/CP" is not precise language because writer/reader are specific types of EPs and CPs. > > IPFIX (Flow Records/Packet Reports) > ^ > ^ | > .----------------------|-+--------------------. > .-----------------------+---------------------.| > | Exporting Process (es) / IPFIX File Writer |' > '----^------------------^---------------------' > | | | > | .-------------|-+--------------------. > | .--------------+---------------------.| > | | Intermediate Process (es) |' > | '--------------^-^-------------------' > | | | > .---+------------------|-+--------------------. > .-----------------------+---------------------.| > | Collecting Process (es) / IPFIX File Reader |' > '-----------------------^---------------------' > | > IPFIX (Flow Records/Packet Reports) > > > Figure E: IPFIX Mediator Component Model with IPFIX File Writer/ > Reader. > > 4.5. Flow Expiration > > > The Aggregation function needs expiration conditions to export cached > Flow Records. These conditions are described in > [I-D.ietf-ipfix-architecture]. In the case of IPFIX Mediation, these > conditions are as follows: > > o If there are no input/received Flow Records/Packet Reports > belonging to a cached Flow for a certain time period, aggregated > Flow Records will expire. This time period should be configurable > at the Intermediate Process. > > o If the IPFIX Mediator experiences resource constraints, aggregated > Flow Records may prematurely expire (e.g., lack of memory to store > > > > Kobayashi, et al. Expires May 8, 2009 [Page 17] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Flow Records). > > o For long-running Flows, the Intermediate Process should expire the > Flow on a regular basis or based on some expiration policy. This > periodicity or expiration policy should be configurable at the > Intermediate Process. > > The Correlation function also needs similar expiration conditions. > However, when cached Flow Records/Packet Reports prematurely expire > and the function can not compute the correlation among them, cached > Flow Records/Packet reports may be discarded. > > 4.6. Information Model > > > IPFIX Mediation reuse the general information model from [RFC5101] > and from [I-D.ietf-psamp-info]. The following new Information > Elements for IPFIX Mediation are also needed. > > +-----+---------------------------+-----+---------------------------+ > | ID | Name | ID | Name | > +-----+---------------------------+-----+---------------------------+ > | XXX | averageBitRate | XXX | averagePacketsRate | > | XXX | minimumBitRate | XXX | minimumPacketsRate | > | XXX | maximumBitRate | XXX | maximumPacketsRate | > +-----+---------------------------+-----+---------------------------+ I'm not sure if we should start exporting "rate" IEs. Rates do not represent stable metrics. It's always better to measure "counts". So, I suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. I do not understand why average rate is needed. You easily get the average rate by dividing the delta count of the entire measurement interval by the interval length. > > 4.7. Examples > > > As example, in case of Intermediate Processes having different > functions, a Collecting Process/IPFIX File Reader replicates Flow > Records/Packet Reports, if necessary, and forwards them to a suitable > Intermediate Process/Exporting Process. Example figure is shown > below. > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 18] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX IPFIX IPFIX > ^ ^ ^ > | | | > .------------. .-----+-------. .-----+-------. .------+------. > | IPFIX File | | Exporting | | Exporting | | Exporting | > | Writer | | Process {i}| | Process {j}|....| Process {n}| > '-----^-^----' '-----^-------' '-----^-------' '------^------' > | | | | | > | +-------------+ | Flow Records > | Flow Records / Packet Reports | > | .------+-------. .-----+--------. .------+-------. > | | Intermediate | | Intermediate | | Intermediate | > | | Process {l} | | Process {m} | | Process {p} | > | | | | |...| | > | | Flow-based | | Flow-based | | | > | | Collector | | Collector | | | > | | Selection | | Selection | | | > Flow Records | ^ | | ^ | | | > | | | | | | | | | > | | Correlation | | Modification| | Modification| > | | ^ | | ^ | | ^ | > | | | | | | | | | | > | | Selection | | Aggregation |...| Selection | > | | ^ | | ^ ^ | | ^ | > | '------|-------' '-----|-|------' '------|-------' > | | | | | > | +---------------+ | Flow Records > | | | | > | Flow Records / Packet Reports | > .------+------. .------+------. .------+------. .-----+------. > | Collecting | | Collecting | | Collecting | | IPFIX File | > | Process {i}| | Process {j}|...| Process {n}| | Reader | > '------^------' '------^------' '------^------' '------------' > | | | > IPFIX IPFIX IPFIX > > Figure F: Functional Block Examples for IPFIX Mediator. > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 19] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 5. Security Considerations > > > IPFIX Mediators use the IPFIX protocol. Security considerations > about Flow Records are described in [RFC5101]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 20] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 6. IANA Considerations > > > This document has no actions for IANA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 21] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 7. References > > > 7.1. Normative References > > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", > draft-ietf-I-D.ietf-ipfix-architectureitecture-12.txt(work > in progress) , September 2006. > > [I-D.ietf-psamp-framework] > Duffield, N., "A Framework for Packet Selection and > Reporting", draft-ietf-psamp-framework-13.txt , June 2008. > > [I-D.ietf-psamp-info] > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > draft-ietf-psamp-info-11.txt (work in progress) , > October 2008. > > [I-D.ietf-psamp-protocol] > Claise, B., Quittek, J., and A. Johnson, "Packet Sampling > (PSAMP) Protocol Specifications", > draft-ietf-psamp-protocol-09.txt , December 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export(IPFIX)", > October 2004. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > January 2008. > > 7.2. Informative References > > > [I-D.boschi-ipfix-anon] > Boschi, E. and B. Trammell, "IP Flow Anonymisation > Support", draft-boschi-ipfix-anon-01.txt (work in > progress) , July 2008. > > [I-D.dressler-ipfix-aggregation] > Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, > "IPFIX Aggregation", > draft-dressler-ipfix-aggregation-05.txt (work in > > > > Kobayashi, et al. Expires May 8, 2009 [Page 22] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > progress) , July 2008. > > [I-D.ietf-ipfix-file] > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "An IPFIX-Based File Format", > draft-ietf-ipfix-file-03.txt(work in progress) , > October 2008. > > [I-D.ietf-ipfix-mediator-ps] > Kobayashi, A., Nishida, H., Sommer, C., Dressler, F., > Stephan, E., and B. Claise, "IPFIX Mediation: Problem > Statement", > draft-ietf-ipfix-mediation-problem-statement-01.txt(work > in progress) , September 2008. > > [I-D.peluso-flowselection] > Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow > selection Techniques", > draft-peluso-flowselection-tech-01.txt(work in progress) , > November 2007. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 23] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Appendix A. Acknowledgements > > > The authors gratefully acknowledge the contributions of > > Keisuke Ishibashi, > Tsuyoshi Kondoh, and > Daisuke Matsubara. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 24] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Authors' Addresses > > Atsushi Kobayashi > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81-422-59-3978 > Email: akoba@nttv6.net > > > Haruhiko Nishida > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81-422-59-3978 > Email: nishida.haruhiko@lab.ntt.co.jp > > > Benoit Claise > Cisco Systems > De Kleetlaan 6a b1 > Diegem 1831 > Belgium > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 25] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 26] --------------ms090403090306060403050005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzEzMjIxOVowIwYJKoZIhvcNAQkEMRYEFL7XIgkNwZgU cezlSaZZd2kTkxGiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBa82jnVj/nL6tx6+LSKitTEr+SUO4gbdkFq5VUMZnScrzkM0ain+VIQ6jP oAnhfuEGmOAlbb61PHOq43f6cq3wZxgjtDUR3715c9QeZV3yVz/xjRVlB7IzmZOc+p/nP40o mGr36kNJwU+Zhqv+kOFet98cPCVLOP5om8PG94t22pqw/mFnApoPX19nmb8IhVRIVFUpS96S +zJDbk5hI9eK7wfpl9G+U0b6R4xYs9q2uYCd1sLTcpc7TM8DQu07hTGrF6Yvi7wu6KPTZN3D 29YDoSv3aBHVEiYIeeMkFhI652V921gyoRpqmSTgDhlLf+jLVuaLqDEXnkK5sAwkWKixAAAA AAAA --------------ms090403090306060403050005-- --===============0915081849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0915081849==-- From ipfix-bounces@ietf.org Mon Nov 17 05:22:19 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3D53A68B4; Mon, 17 Nov 2008 05:22:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42713A689D for ; Mon, 17 Nov 2008 05:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGmVzW-KE0-a for ; Mon, 17 Nov 2008 05:22:14 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id BD7A83A688B for ; Mon, 17 Nov 2008 05:22:13 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 740BA47B59 for ; Mon, 17 Nov 2008 14:22:11 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 63CC192D for ; Mon, 17 Nov 2008 14:22:11 +0100 (CET) Message-ID: <4921700B.1040602@net.in.tum.de> Date: Mon, 17 Nov 2008 14:22:19 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "ipfix@ietf.org" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0915081849==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0915081849== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090403090306060403050005" This is a cryptographically signed message in MIME format. --------------ms090403090306060403050005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Atsushi, all, I reviewed the mediator framework draft. In my opinion, it already is in a very good shape. The scope is clear and the description of the different mediator functions is comprehensive. I'm not sure about the "Flow-based Collector Selection". It does not seem to be a new function but rather a use-case of the "Flow Selection Function" (plus Exporting Process, see comments below). Probably, you should not reference future drafts that are supposed to provide technical solutions (such as IPFIX anonymization and aggregation drafts) because we do not know how the solutions will look like. RFC3917 does not reference any early IPFIX protocol draft, either. Some more examples for specific mediator use-cases might be useful. Regards, Gerhard > IPFIX Working Group A. Kobayashi > Internet-Draft H. Nishida > Intended status: Informational NTT PF Lab. > Expires: May 8, 2009 B. Claise > Cisco Systems > November 4, 2008 > > > > IPFIX Mediation: Framework > > > draft-ietf-ipfix-mediators-framework-01 > > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > applicable patent or other IPR claims of which he or she is aware > have been or will be disclosed, and any of which he or she becomes > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > 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." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 8, 2009. > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 1] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Abstract > > This document describes a framework for an IPFIX Mediation. This "for an IPFIX Mediator" or "for IPFIX Mediation" > framework details an IPFIX Mediation reference model and the > components of the IPFIX Mediation device (IPFIX Mediator). > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 9 > 4. IPFIX Mediation Functional and Logical Blocks . . . . . . . . 12 > 4.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 12 > 4.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 12 > 4.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 12 > 4.3.1. Flow Selection Function . . . . . . . . . . . . . . . 12 > 4.3.2. Flow-based Collector Selection Function . . . . . . . 13 > 4.3.3. Aggregation Function . . . . . . . . . . . . . . . . . 13 > 4.3.4. Correlation Function . . . . . . . . . . . . . . . . . 14 > 4.3.5. Modification Function . . . . . . . . . . . . . . . . 15 > 4.4. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 16 > 4.5. Flow Expiration . . . . . . . . . . . . . . . . . . . . . 17 > 4.6. Information Model . . . . . . . . . . . . . . . . . . . . 18 > 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 > Intellectual Property and Copyright Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 2] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 1. Introduction > > > IPFIX Mediation reroutes, replicates, filters, aggregates, > correlates, or modifies Flow Records/Packet Reports or changes a > transport protocol. This document describes the framework for IPFIX > Mediation. The motivation for the IPFIX Mediation standard comes > from the need for flow-based measurement system support for large- > scale networks, interdomain networks, and coexistence with > traditional Exporters as described in detail in > [I-D.ietf-ipfix-mediator-ps]. The standard specification requires a > definition of IPFIX Mediation and IPFIX Mediation device (IPFIX > Mediator). I would not introduce "IPFIX Mediation device" as a synonym for "IPFIX Mediator". > > This document is organized as follows. Section 2 describes > terminology related to IPFIX Mediation. Section 3 describes a high > level reference model. Section 4 details the components of the IPFIX > Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 3] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 2. Terminology > > > The terms in this section are in line with those in the IPFIX > specification document [RFC5101] and the PSAMP specification document > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX Terms from RFC5101 and psamp-protocol should not be repeated. > Mediation are also defined with those in the IPFIX Mediator problem > statement [I-D.ietf-ipfix-mediator-ps]. All these terms are > capitalized in this document. > > Observation Point > > An Observation Point is a location in the network where IP packets > can be observed. Examples include: a line to which a probe is > attached, a shared medium, such as an Ethernet-based LAN, a single > port of a router, or a set of interfaces (physical or logical) of > a router. > > Note that every Observation Point is associated with an > Observation Domain (defined below), and that one Observation Point > may be a superset of several other Observation Points. For > example, one Observation Point can be an entire line card. That > would be the superset of the individual Observation Points at the > line card's interfaces. > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IPFIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain IDs > also be unique per IPFIX Device. > > Flow Key > > Each of the fields that: > > 1. belong to the packet header (e.g., destination IP address), > > 2. are a property of the packet itself (e.g., packet length), > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > number), > > > > Kobayashi, et al. Expires May 8, 2009 [Page 4] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > and that are used to define a Flow are termed Flow Keys. > > Flow Record > > A Flow Record contains information about a specific Flow that was > observed at an Observation Point. A Flow Record contains measured > properties of the Flow (e.g., the total number of bytes for all > the Flow's packets) and usually characteristic properties of the > Flow (e.g., source IP address). > > Packet Reports > > Packet Reports comprise a configurable subset of a packet's input > to the Selection Process, including the Packet Content, > information relating to its treatment (for example, the output > interface), and its associated selection state (for example, a > hash of the Packet Content). > > Exporting Process > > The Exporting Process sends Flow Records to one or more Collecting > Processes. The Flow Records are generated by one or more Metering > Processes. > > Exporter > > A device that hosts one or more Exporting Processes is termed an > Exporter. > > IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting Processes and arbitrary numbers of Observation > Points and Metering Processes. > > Collecting Process > > A Collecting Process receives Flow Records from one or more > Exporting Processes. The Collecting Process might process or > store received Flow Records, but such actions are out of the scope > of this document. > > Collector > > A device that hosts one or more Collecting Processes is termed a > Collector. > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 5] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX Message > > An IPFIX Message is a message originating at the Exporting Process > that carries the IPFIX records of this Exporting Process and whose > destination is a Collecting Process. An IPFIX Message is > encapsulated at the transport layer. > > Information Element > > An Information Element is a protocol and encoding-independent > description of an attribute that may appear in an IPFIX Record. > The IPFIX information model [RFC5102] defines the base set of > Information Elements for IPFIX. The type associated with an > Information Element indicates constraints on what it may contain > and also determines the valid encoding mechanisms for use in > IPFIX. > > IPFIX Mediation > > An IPFIX Mediation is a generic term for functions doing something > for Flow Records, Packet Reports, and IPFIX Messages. IPFIX > Mediation is located in between components: Metering Processes, > Exporting Processes, Collecting Processes, and other applications. > IPFIX Mediation can be included in any IPFIX Devices. IPFIX > Mediation consists of a set of some of the following functions: > > * rerouting input Flow Records/Packet Reports to an appropriate > Collecting Process > > * replicating input Flow Records/Packet Reports > > * filtering and selecting input Flow Records/Packet Reports > > * aggregating input Flow Records/Packet Reports based on new Flow > Keys > > * correlating a set of Flow Records/Packet Reports for creating > new Flow Records/Packet Reports with new metrics > > * modifying input Flow Records/Packet Reports > > * changing transport protocols that carry IPFIX Messages > > The modification of Flow Records/Packet Reports includes these > processes: > > * changing the value of specified Information Elements > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 6] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > * adding new Information Elements by deriving further Flow or > packet properties from existing fields or calculating new > metrics > > * deleting specified Information Elements. > > IPFIX Mediation can be included in any device, such as routers, > switches, NMS (Network Management Systems), or stand-alone > devices. > > Flow-Based Collector Selection > > The Flow-Based Collector Selection evaluates an input Flow Record/ > Packet Report based on the value of the specified Information > Element and then selects a Collector for each input Flow Record/ > Packet Report. > > IPFIX Mediator > > An IPFIX Mediator contains one or more functions defined in IPFIX > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > device. It also contains one or more Collecting Processes and one > or more Exporting Processes. > > Original Exporter > > An Original Exporter is an IPFIX Device that hosts Observation > Points where IP packets can be directly observed. > > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter and sends IPFIX Messages to one or more > Collectors. It may alter part of an IPFIX Message to comply with > IPFIX Protocol specifications. It may also change the type of > transport protocol, such as UDP, TCP, SCTP, and PR-SCTP, and > convert a legacy protocol message to an IPFIX Message, if > necessary. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > Records/Packet Reports, aggregates them, then exports the > aggregated Flow Records. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 7] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > Records/Packet Reports based on the result of Flow-Based Collector > Selection. It may filter or replicate input Flow Records/Packet > Reports, if necessary. > > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data of input Flow Records/Packet Reports according > to configured policies. It can thus, for example, hide the > network topology information or customers' IP addresses. > > Intermediate Process > > An Intermediate Process in IPFIX Mediators can be considered as a > partial Metering Process taken from the Metering Process in > Original Exporters as described in [RFC3917]. I do not like the definition of IP as "partial MP". This creates confusion and makes it difficult to distinguish MPs and IPs. > > The Intermediate Process generates new sets of Data Records/Packet > Reports from input Data Records/Packet Reports. > > Mediator Observation Domain > > An IPFIX Mediator does not host the Observation Points and Why should we disallow IPFIX Mediators which also have native Observation Points? > Observation Domain. The Observation Domain ID in the IPFIX header > sent by the IPFIX Mediator also indicates the largest set of > Observation Points from the viewpoint of a Collector. However, This seems to be too generic. The ODID issued by the mediator should identify the set of ODs/OPs the exported records belong to. It does not always have to be the "largest set of OPs", it can be a subset. As an example, the Mediator may be configured not to merge records from different OPs at all. In this case, we can keep the old OIDs. Or it may be configured to merge records from a specific subset of OPs only. > this value does not indicate the physical entity of an Original > Exporter. > > Transport Session Information > > The Transport Session is specified in [RFC5101]. In SCTP, the > Transport Session Information is the SCTP association. In TCP and > UDP, the Transport Session Information corresponds to a 5-tuple > {Exporter IP address, Collector IP address, Exporter transport > port, Collector transport port, and transport protocol}. > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 8] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 3. IPFIX Mediation Reference Model > > > The figure below shows the high-level reference model for IPFIX > Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > the various possible scenarios that can exist in an IPFIX measurement > system. > > > +---------------------------+ +---------------------------+ > | Collector {l} | | Collector {k} | > |[*Application(s)] | |[*Application(s)] | > |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > |[Collecting Process(es)] |....|[Collecting Process(es)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ ^ > | | | | > | +------....----+ | > | | | > IPFIX (Flow Records / Packet Reports) > | | | > +----------------+----+-----+ +-------+-------------------+ > |IPFIX Mediator {j} | |IPFIX Mediator {n} | > |[*Applications(s)] | |[*Applications(s)] | > |[Exporting Process(es)] | |[Exporting Process(es)] | > |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > |[Collecting Process(es)] | |[Collecting Process(es)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ > | | | > | +------....-----+ > | | > IPFIX (Flow Records / Packet Reports) > | | > +----------------+----------+ +----+----------------------+ > |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > |[Exporting Process(es)] | |[Exporting Process(es)] | > |[Metering Process(es)] |....|[Metering Process(es)] | > |[Observation Point(s)] | |[Observation Point(s)] | > +---------------------------+ +---------------------------+ > ^ ^ ^ ^ > | | | | > Packets coming in to Observation Points > > Figure A: Reference Model for IPFIX Mediation. > > The various functional components are indicated within brackets []. > The functional components within [*] are not part of > [I-D.ietf-ipfix-architecture]. Hm. Intermediate Process as well as IPFIX reader/writer are not part of ipfix-architecture either. BTW: IPFIX reader/writer are considered as special types of CPs and EPs. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 9] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > The figure below shows the basic IPFIX Mediator component model. The > IPFIX Mediator is formally defined to consist of one or more > Collecting Processes, zero or more Intermediate Processes, and one or > more Exporting Processes. Basically, IPFIX Mediator devices, i.e., > IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor, and IPFIX > Concentrator, described in [I-D.ietf-ipfix-mediator-ps], are composed > of these components. > > > IPFIX(Flow Records/Packet Reports) > ^ > ^ | > +------------------------|-|---------------------+ > | IPFIX Mediator | | | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Exporting Process (es) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Intermediate Process (es) (optional) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Collecting Process (es) |' | > | '----------------------^--------------------' | > +------------------------|-|---------------------+ > | > IPFIX(Flow Records/Packet Reports) > > Figure B: IPFIX Mediator Basic Component Model. > > An Original Exporter with a Mediation function is modeled as follows. > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 10] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX (Flow Records/Packet Reports) > ^ ^ > +---------------------------|-|------------------------+ > | Original Exporter | | | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Exporting Process(es) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Intermediate Process(es) |' | > | '---------^-----------------------^---------' | > | |Flow Record or | | > | | Packet Reports | | > | .------------+----------. .---------+-------------. | > | | Metering Process {i} |..| Metering Process {n} | | > | '------------^----------' '---------^-------------' | > | | | | > | .------------+----------. .---------+-------------. | > | | Observation Point {i} |..| Observation Point {n} | | > | '------------^----------' '---------^-------------' | > +--------------|-----------------------|---------------+ > | | > Packets coming in to Observation Points > > Figure C: Component Model for Original Exporter with Mediation. > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 11] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 4. IPFIX Mediation Functional and Logical Blocks > > > The section describes the details of each component and examples > applicable to that component for IPFIX Mediation and IPFIX Mediator. > > 4.1. Collecting Process > > > The Collecting Processes described in [RFC5101] receive Flow Records/ > Packet Reports with information relating to their treatment in the > Metering Process and Exporting Process in the Original Exporter, such > as sampling rate, IPFIX header information, and Transport Session > Information. The Collecting Processes forward the set of data to > multiple components: Intermediate Processes and Exporting Processes. > In other words, the processes may duplicate received Flow Records/ > Packet Reports and forward them to multiple components in sequence or > in parallel. > > 4.2. Exporting Process > > > The Exporting Processes described in [RFC5101] forward Flow Records/ better verb for "forward"? e.g. "transmit"? > Packet Reports to one or multiple Collectors. The processes manage > the reporting Template and make IPFIX Messages. > > 4.3. Intermediate Process > > > Intermediate Processes generate new sets of Flow Records/Packet > Reports from input Flow Records/Packet Reports with IPFIX header > information "Export Time" and "Observation Domain ID". The processes I would not call it "IPFIX header information" because there are no IPFIX Messages at the input of the Intermediate Process, only Records. Maybe "context information collected at the Collecting Process"? > host one of several functions defined below or a combination of them, > in any sequence or in any set. In the case of a combination, the > output of each function can be the input of other functions. The > following subsections show the details of each function. > > 4.3.1. Flow Selection Function > > > The Flow Selection function determines which input Flow Records/ > Packet Reports are selected by matching under a filtering policy and > then forwards them to the next processes or functions. The function > is similar to the Selection Process described in > [I-D.ietf-psamp-framework]. The function covers several selection > techniques, such as property match filtering and Flow selection, > which are described in [I-D.ietf-psamp-framework] and > [I-D.peluso-flowselection], respectively. In property match > filtering, if the value of a specified Information Element equals a > configured value, the function selects Flow Records/Packet Reports to > forward. > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 12] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 4.3.2. Flow-based Collector Selection Function > > > The Flow-based Collector Selection function determines to which > Collector input Flow Records/Packet Reports are exported. The > function may also determine the type of Transport Session. The This functional description conflicts with the Exporting Process. In my opinion, the Exporting Process holds the information about the Collectors, transport protocol etc. > function evaluates the value of a specified Information Element in > input Flow Records/Packet Reports and then selects the Collector. So, what is the difference between Flow-Based Colelctor Selection Function and Flow Selection Function plus Exporting Process? I'm not sure if Flow-based Collector Selection should be a function of its own. I would rather say that it describes a use-case of one or multiple Flow Selection Functions and Exporting Processes: +--> Flow Selector 1 -> EP 1 ----+ +--> Flow Selector 2 -> EP 2 > These selection criteria are similar to the property match filtering > in Mediator Selection Function. > > Applicable examples include exporting Flow Records/Packet Reports to > a dedicated Collector on the basis of customers or organizations > peering. The function classifies Flow Records/Packet Reports on the > basis of a peering AS number, as shown in the following figure. The > set of classified Flow Records/Packet Reports is exported to a > dedicated Collector on the basis of the peering AS number. > > .----------------------------. > | Intermediate Process | > | .----------------------. | > | | Flow-Based Collector | | > | | Selection Function | | > | | | | > | | Peering AS #10 | | > | | +-------------------+-+---> Collector #1 > | | | Peering AS #20 | | > Flow --+---+--+-------------------+-+---> Collector #2 > Records | | | Peering AS #30 | | > | | +-------------------+-+---> Collector #3 > | '----------------------' | > '----------------------------' > > Figure D: Exporting classified Flow Records to dedicated Collector. > > 4.3.3. Aggregation Function > > > The Aggregation function creates aggregated Flow Records from input > Flow Records/Packet Reports. The aggregation method is divided into > three types: > > Choosing Shorter Flow Key > > Choosing a shorter Flow Key than the Flow Key of input Flow A "shorter Flow Key" would be an IP address of 8 bits. That is not what you mean. You rather decrease the number of fields considered as Flow Keys. > Records, such as three, two, or a single Flow Key, can create more "Flow Key field" > aggregated Flow Records. The function gathers Flow Records/Packet > Reports within a given interval time and then distinguishes Flow > Records/Packet Reports that have common properties. If values of It sounds strange to distinguish records that have common properties. You rather want to merge them. > a given key field are the same, that means those Flow Records/ > > > > Kobayashi, et al. Expires May 8, 2009 [Page 13] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Packet Reports have common properties, and the function merges > them in accordance with aggregation rules described in > [I-D.dressler-ipfix-aggregation]. > > In addition, the function can create statistical data and > subsidiary information related to the aggregated Flow Records. > Examples include the number of input Flow Records/Packet Reports, > the given interval time, and a set of a new Flow Key. "a new set of Flow Keys" (a Flow Key is a single field!) > > Time Composition > > Time composition is defined as aggregation with the same Flow Key "identical Flow Key values" > for long-running Flows. The function may also compute Flow > Records statistics, such as average, maximum, and minimum value of > each counter. The statistics help to visualize the behavior of > traffic volume over a long time period. > > As another approach, the function collects Flow Records/Packet > Reports of a shorter time period from an Original Exporter, and > then computes these statistics. Even if output Flow Records of > the function indicate a general time period, the accuracy of the > minimum, maximum, and average value can be improved. Where is the difference to what you described in the preceding paragraph? > > Space Composition > > Space composition is defined as aggregation on a larger > Observation Domain or on a set of Observation Points. In that > case, a Flow key can be applied to other properties, such as What do you mean by "a Flow Key can be applied to "? > Exporter IP address and Observation Domain ID. > > In addition, a group identifier indicating a spatial Observation > Domain can also become a new Flow Key. For example, a group can > indicate an area on an ISP network, or a link aggregation > interface composd of physical interfaces. The group can also make > a relation to a set of values of specified Information Elements in > Flow Records by the configuring rule. After converting from the > values of specified Information Elements to the group identifier, > the function can create aggregated Flow Records by a general > aggregation process. > > 4.3.4. Correlation Function > > > The Correlation function creates new metrics from by evaluating the > correlation among sets of Flow Records/Packets Records. These sets > can be Flow Records gathered during a certain period, a pair of > consecutive Packet Reports, or Packet Reports exported by different > Exporters indicating the same packet. After offering new metrics, > the function outputs Flow Records with the new metrics field. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 14] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Applicable examples are as follows. > > o One way delay follows from correlating Packet Reports exported > from different Exporters on the path. > > o Packet interval time, or jitter, follows from correlating > consecutive Packet Reports exported from the same Exporter. > > o Difference values follow from correlating Flow Records observed at > ingress or egress interfaces. The values help to confirm the > result of a queueing or rate-limiting function. > > o Average/maximum/minimum values follow from correlating each in a > set of Flow Records. > > 4.3.5. Modification Function > > > The Modification function modifies input Flow Records/Packet Reports > without changing their granularity. The function can add new > Information Elements, delete existing Information Elements, or modify > the value of specified Information Elements. If the function > modifies the data structure of an original Template, it also needs to > modify the value of the "flowKeyIndicator". > > Adding specified Information Elements > > The function obtains the value of a specified Information Element > and then adds it into Flow Records/Packet Reports. There are > several methods to obtain the value: retrieving the value from a > database or calculating the value based on the value of other > Information Elements and received traffic data. > > Applicable examples include adding derived packet property > parameters instead of Original Exporters. Doing that can remove "instead of Original Exporters" > compensate for traditional Exporters or probes unable to add > packet property parameters. Therefore, Collectors do not need to > recognize the difference among implementations of routers from > several vendors or among Exporter types, such as router, switch, > or probe. Typical derived packet property parameters include the > following. > > * The "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] > indicates the egress router of a network domain. That is > useful for making a traffic matrix that covers the whole > network domain. > > * The BGP Community value indicates the same group of destination > or source IP addresses. > > > > Kobayashi, et al. Expires May 8, 2009 [Page 15] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > * The "mplsVpnRouteDistinguisher" described in [RFC5102], which > cannot be extracted from the core router in MPLS networks, > indicates the VPN customer's identification. Network operators > can monitor the traffic behavior of each customer by adding > "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports. > > Deleting specified Information Elements > > This function deletes existing Information Elements according to > instruction rules, which indicate whether an Information Element > should be removed. > > Applicable examples include hiding network topology information > and private information. In the case of IPFIX exporting across > domains, the function can avoid making a vulnerability by deleting > unnecessary Information Elements. Examples of network topology > information include "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4| > v6}Address", and "bgp{Next|Prev}AdjacentAsNumber", described in > [RFC5102]. In addition, MPLS-related Information Elements, such > as "mplsLabelStackSection", are useless for customers in the case > of feeding Flow Records/Packet Reports to VPN customers. > > Modifying the value of specified Information Elements > > This function modifies the value of specified Information > Elements. > > Applicable examples include anonymizing customers' private > information, such as IP address and port number, according to a > privacy protection policy. Several annonymization techniques are > described in [I-D.boschi-ipfix-anon]. The function also reports > anonymization methods and part of anonymized data as subsidiary > information. > > 4.4. IPFIX File Writer/Reader > > > The IPFIX File Writer stores input Flow Records/Packet Reports from > any process in a storage system. If received Flow Records/Packet It's a "file system". > Reports include uninteresting Information Elements, the Modification > Function can delete these elements before the IPFIX File Writer > handles them. Therefore, IPFIX File Writers can accept input from > any process. In either case, input needs to include the IPFIX header Remove the whole sentence "Therefore,..." > information and the Transport Session Information along with Flow > Records/Packet Reports. Why does the File Writer require header information and transport session information as input? We should not specify additional restrictions for the File Writer here. Also, there are cases where there are no headers and no transport sessions, e.g. if the writer is linked to a Metering Process. > > In contrast, the IPFIX File Reader retrieves stored Flow Records/ > Packet Reports when operators want to retrieve past Flow Records/ > Packet Reports on the basis of a given time period. If the data > > > > Kobayashi, et al. Expires May 8, 2009 [Page 16] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > structure of output Flow Records/Packet Reports from the IPFIX File > Reader is different from what operators want, the Modification > function can modify the data structure. Therefore, the output of > IPFIX File Readers can be input to any components. The IPFIX File > Writer/Reader are described in [I-D.ietf-ipfix-file] in detail. > > The figure shows the IPFIX component model with IPFIX File Writer/ > Reader. IPFIX File Writer/Reader are located in the same position of > Exporting Process/Collecting Process, respectively. According to ipfix-file, IPFIX File Writer/Reader operate as EP/CP. So, "located in the same position of EP/CP" is not precise language because writer/reader are specific types of EPs and CPs. > > IPFIX (Flow Records/Packet Reports) > ^ > ^ | > .----------------------|-+--------------------. > .-----------------------+---------------------.| > | Exporting Process (es) / IPFIX File Writer |' > '----^------------------^---------------------' > | | | > | .-------------|-+--------------------. > | .--------------+---------------------.| > | | Intermediate Process (es) |' > | '--------------^-^-------------------' > | | | > .---+------------------|-+--------------------. > .-----------------------+---------------------.| > | Collecting Process (es) / IPFIX File Reader |' > '-----------------------^---------------------' > | > IPFIX (Flow Records/Packet Reports) > > > Figure E: IPFIX Mediator Component Model with IPFIX File Writer/ > Reader. > > 4.5. Flow Expiration > > > The Aggregation function needs expiration conditions to export cached > Flow Records. These conditions are described in > [I-D.ietf-ipfix-architecture]. In the case of IPFIX Mediation, these > conditions are as follows: > > o If there are no input/received Flow Records/Packet Reports > belonging to a cached Flow for a certain time period, aggregated > Flow Records will expire. This time period should be configurable > at the Intermediate Process. > > o If the IPFIX Mediator experiences resource constraints, aggregated > Flow Records may prematurely expire (e.g., lack of memory to store > > > > Kobayashi, et al. Expires May 8, 2009 [Page 17] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Flow Records). > > o For long-running Flows, the Intermediate Process should expire the > Flow on a regular basis or based on some expiration policy. This > periodicity or expiration policy should be configurable at the > Intermediate Process. > > The Correlation function also needs similar expiration conditions. > However, when cached Flow Records/Packet Reports prematurely expire > and the function can not compute the correlation among them, cached > Flow Records/Packet reports may be discarded. > > 4.6. Information Model > > > IPFIX Mediation reuse the general information model from [RFC5101] > and from [I-D.ietf-psamp-info]. The following new Information > Elements for IPFIX Mediation are also needed. > > +-----+---------------------------+-----+---------------------------+ > | ID | Name | ID | Name | > +-----+---------------------------+-----+---------------------------+ > | XXX | averageBitRate | XXX | averagePacketsRate | > | XXX | minimumBitRate | XXX | minimumPacketsRate | > | XXX | maximumBitRate | XXX | maximumPacketsRate | > +-----+---------------------------+-----+---------------------------+ I'm not sure if we should start exporting "rate" IEs. Rates do not represent stable metrics. It's always better to measure "counts". So, I suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. I do not understand why average rate is needed. You easily get the average rate by dividing the delta count of the entire measurement interval by the interval length. > > 4.7. Examples > > > As example, in case of Intermediate Processes having different > functions, a Collecting Process/IPFIX File Reader replicates Flow > Records/Packet Reports, if necessary, and forwards them to a suitable > Intermediate Process/Exporting Process. Example figure is shown > below. > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 18] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > IPFIX IPFIX IPFIX > ^ ^ ^ > | | | > .------------. .-----+-------. .-----+-------. .------+------. > | IPFIX File | | Exporting | | Exporting | | Exporting | > | Writer | | Process {i}| | Process {j}|....| Process {n}| > '-----^-^----' '-----^-------' '-----^-------' '------^------' > | | | | | > | +-------------+ | Flow Records > | Flow Records / Packet Reports | > | .------+-------. .-----+--------. .------+-------. > | | Intermediate | | Intermediate | | Intermediate | > | | Process {l} | | Process {m} | | Process {p} | > | | | | |...| | > | | Flow-based | | Flow-based | | | > | | Collector | | Collector | | | > | | Selection | | Selection | | | > Flow Records | ^ | | ^ | | | > | | | | | | | | | > | | Correlation | | Modification| | Modification| > | | ^ | | ^ | | ^ | > | | | | | | | | | | > | | Selection | | Aggregation |...| Selection | > | | ^ | | ^ ^ | | ^ | > | '------|-------' '-----|-|------' '------|-------' > | | | | | > | +---------------+ | Flow Records > | | | | > | Flow Records / Packet Reports | > .------+------. .------+------. .------+------. .-----+------. > | Collecting | | Collecting | | Collecting | | IPFIX File | > | Process {i}| | Process {j}|...| Process {n}| | Reader | > '------^------' '------^------' '------^------' '------------' > | | | > IPFIX IPFIX IPFIX > > Figure F: Functional Block Examples for IPFIX Mediator. > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 19] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 5. Security Considerations > > > IPFIX Mediators use the IPFIX protocol. Security considerations > about Flow Records are described in [RFC5101]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 20] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 6. IANA Considerations > > > This document has no actions for IANA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 21] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > 7. References > > > 7.1. Normative References > > > [I-D.ietf-ipfix-architecture] > Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > "Architecture for IP Flow Information Export", > draft-ietf-I-D.ietf-ipfix-architectureitecture-12.txt(work > in progress) , September 2006. > > [I-D.ietf-psamp-framework] > Duffield, N., "A Framework for Packet Selection and > Reporting", draft-ietf-psamp-framework-13.txt , June 2008. > > [I-D.ietf-psamp-info] > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > Carle, "Information Model for Packet Sampling Exports", > draft-ietf-psamp-info-11.txt (work in progress) , > October 2008. > > [I-D.ietf-psamp-protocol] > Claise, B., Quittek, J., and A. Johnson, "Packet Sampling > (PSAMP) Protocol Specifications", > draft-ietf-psamp-protocol-09.txt , December 2007. > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > "Requirements for IP Flow Information Export(IPFIX)", > October 2004. > > [RFC5101] Claise, B., "Specification of the IP Flow Information > Export (IPFIX) Protocol for the Exchange of IP Traffic > Flow Information", January 2008. > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > Meyer, "Information Model for IP Flow Information Export", > January 2008. > > 7.2. Informative References > > > [I-D.boschi-ipfix-anon] > Boschi, E. and B. Trammell, "IP Flow Anonymisation > Support", draft-boschi-ipfix-anon-01.txt (work in > progress) , July 2008. > > [I-D.dressler-ipfix-aggregation] > Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, > "IPFIX Aggregation", > draft-dressler-ipfix-aggregation-05.txt (work in > > > > Kobayashi, et al. Expires May 8, 2009 [Page 22] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > progress) , July 2008. > > [I-D.ietf-ipfix-file] > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > Wagner, "An IPFIX-Based File Format", > draft-ietf-ipfix-file-03.txt(work in progress) , > October 2008. > > [I-D.ietf-ipfix-mediator-ps] > Kobayashi, A., Nishida, H., Sommer, C., Dressler, F., > Stephan, E., and B. Claise, "IPFIX Mediation: Problem > Statement", > draft-ietf-ipfix-mediation-problem-statement-01.txt(work > in progress) , September 2008. > > [I-D.peluso-flowselection] > Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow > selection Techniques", > draft-peluso-flowselection-tech-01.txt(work in progress) , > November 2007. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 23] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Appendix A. Acknowledgements > > > The authors gratefully acknowledge the contributions of > > Keisuke Ishibashi, > Tsuyoshi Kondoh, and > Daisuke Matsubara. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 24] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Authors' Addresses > > Atsushi Kobayashi > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81-422-59-3978 > Email: akoba@nttv6.net > > > Haruhiko Nishida > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81-422-59-3978 > Email: nishida.haruhiko@lab.ntt.co.jp > > > Benoit Claise > Cisco Systems > De Kleetlaan 6a b1 > Diegem 1831 > Belgium > > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 25] > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > Full Copyright Statement > > Copyright (C) The IETF Trust (2008). > > This document is subject to the rights, licenses and restrictions > contained in BCP 78, and except as set forth therein, the authors > retain all their rights. > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Intellectual Property > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 26] --------------ms090403090306060403050005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzEzMjIxOVowIwYJKoZIhvcNAQkEMRYEFL7XIgkNwZgU cezlSaZZd2kTkxGiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBa82jnVj/nL6tx6+LSKitTEr+SUO4gbdkFq5VUMZnScrzkM0ain+VIQ6jP oAnhfuEGmOAlbb61PHOq43f6cq3wZxgjtDUR3715c9QeZV3yVz/xjRVlB7IzmZOc+p/nP40o mGr36kNJwU+Zhqv+kOFet98cPCVLOP5om8PG94t22pqw/mFnApoPX19nmb8IhVRIVFUpS96S +zJDbk5hI9eK7wfpl9G+U0b6R4xYs9q2uYCd1sLTcpc7TM8DQu07hTGrF6Yvi7wu6KPTZN3D 29YDoSv3aBHVEiYIeeMkFhI652V921gyoRpqmSTgDhlLf+jLVuaLqDEXnkK5sAwkWKixAAAA AAAA --------------ms090403090306060403050005-- --===============0915081849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0915081849==-- From ipfix-bounces@ietf.org Mon Nov 17 05:45:27 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336EC3A686E; Mon, 17 Nov 2008 05:45:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8393A686E for ; Mon, 17 Nov 2008 05:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fXXPZJphVwc for ; Mon, 17 Nov 2008 05:45:24 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 42EA33A6941 for ; Mon, 17 Nov 2008 05:45:24 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E2D8547B5C; Mon, 17 Nov 2008 14:45:19 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id D1CF71539; Mon, 17 Nov 2008 14:45:19 +0100 (CET) Message-ID: <49217578.4010707@net.in.tum.de> Date: Mon, 17 Nov 2008 14:45:28 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nevil Brownlee References: <4910D077.9030201@auckland.ac.nz> In-Reply-To: <4910D077.9030201@auckland.ac.nz> X-Virus-Scanned: ClamAV using ClamSMTP Cc: IPFIX Working Group Subject: Re: [IPFIX] New Drafts - please check the changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1128697357==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1128697357== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040106030501010808070808" This is a cryptographically signed message in MIME format. --------------ms040106030501010808070808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, All of my comments to the IPFIX MIB -04 draft have been been addressed in the new version. Small comment to the authors: I've found two occurrences of "Exported Template table" in the text. I assume that "Exported" should be removed in both cases. Regards, Gerhard Nevil Brownlee wrote: > > Hi all: > > The drafts listed below have been recently published, following > their WG Last Calls. If you raised any concerns about them earlier, > please check the new versions and let us know (on this list) if > you have any remaining issues. > > Provided no further issues are raised before our session at IETF 73 > in Minneapolis, or at that session, we will write up their Shepherding > reports and submit them to IESG for publication as RFCs. > > - draft-ietf-ipfix-mib-05.txt > > - draft-ietf-ipfix-export-per-sctp-stream-01.txt > - draft-ietf-ipfix-exporting-type-02.txt > - draft-ietf-ipfix-file-03.txt > > Cheers, Nevil > --------------ms040106030501010808070808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzEzNDUyOFowIwYJKoZIhvcNAQkEMRYEFFHF684xnmIQ pNfkedYIC92olGQtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQC/qAOhW5733iEwrH+BVvOMxkzjb09MI/SdvgyUW6QIfVsvUYt4/yp1sA0f V75BaMLkH5S5o/kt9bVn6WFaKmPZzUODoTzYNKO5oMkSgSAs0xHhQzKIg+xbOA476b+w1mEo CVWs4FgeZTDxbty8QqdKXDGcFduMbihZ6dGMPcW2JMTmcJm86AoG8nnKJewy9NZ8gd1XR9NR T5z5oGOXK4p/oCFn3EpwGcHxUTTZ36HAIYGsj1hN/o4wv5tq3472Lmr1g10gR5cI2fkdcCBP U4aW9qgYUCP2+x+YIe33ch7v9s0KABJ/WBHlpBv9ctOYk3qkW9Gvt6cUpNmpuUJeqXdxAAAA AAAA --------------ms040106030501010808070808-- --===============1128697357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1128697357==-- From ipfix-bounces@ietf.org Mon Nov 17 05:45:27 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336EC3A686E; Mon, 17 Nov 2008 05:45:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8393A686E for ; Mon, 17 Nov 2008 05:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fXXPZJphVwc for ; Mon, 17 Nov 2008 05:45:24 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 42EA33A6941 for ; Mon, 17 Nov 2008 05:45:24 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E2D8547B5C; Mon, 17 Nov 2008 14:45:19 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id D1CF71539; Mon, 17 Nov 2008 14:45:19 +0100 (CET) Message-ID: <49217578.4010707@net.in.tum.de> Date: Mon, 17 Nov 2008 14:45:28 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nevil Brownlee References: <4910D077.9030201@auckland.ac.nz> In-Reply-To: <4910D077.9030201@auckland.ac.nz> X-Virus-Scanned: ClamAV using ClamSMTP Cc: IPFIX Working Group Subject: Re: [IPFIX] New Drafts - please check the changes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1128697357==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1128697357== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040106030501010808070808" This is a cryptographically signed message in MIME format. --------------ms040106030501010808070808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, All of my comments to the IPFIX MIB -04 draft have been been addressed in the new version. Small comment to the authors: I've found two occurrences of "Exported Template table" in the text. I assume that "Exported" should be removed in both cases. Regards, Gerhard Nevil Brownlee wrote: > > Hi all: > > The drafts listed below have been recently published, following > their WG Last Calls. If you raised any concerns about them earlier, > please check the new versions and let us know (on this list) if > you have any remaining issues. > > Provided no further issues are raised before our session at IETF 73 > in Minneapolis, or at that session, we will write up their Shepherding > reports and submit them to IESG for publication as RFCs. > > - draft-ietf-ipfix-mib-05.txt > > - draft-ietf-ipfix-export-per-sctp-stream-01.txt > - draft-ietf-ipfix-exporting-type-02.txt > - draft-ietf-ipfix-file-03.txt > > Cheers, Nevil > --------------ms040106030501010808070808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExNzEzNDUyOFowIwYJKoZIhvcNAQkEMRYEFFHF684xnmIQ pNfkedYIC92olGQtMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQC/qAOhW5733iEwrH+BVvOMxkzjb09MI/SdvgyUW6QIfVsvUYt4/yp1sA0f V75BaMLkH5S5o/kt9bVn6WFaKmPZzUODoTzYNKO5oMkSgSAs0xHhQzKIg+xbOA476b+w1mEo CVWs4FgeZTDxbty8QqdKXDGcFduMbihZ6dGMPcW2JMTmcJm86AoG8nnKJewy9NZ8gd1XR9NR T5z5oGOXK4p/oCFn3EpwGcHxUTTZ36HAIYGsj1hN/o4wv5tq3472Lmr1g10gR5cI2fkdcCBP U4aW9qgYUCP2+x+YIe33ch7v9s0KABJ/WBHlpBv9ctOYk3qkW9Gvt6cUpNmpuUJeqXdxAAAA AAAA --------------ms040106030501010808070808-- --===============1128697357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1128697357==-- From ipfix-bounces@ietf.org Mon Nov 17 11:16:40 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0483A69A3; Mon, 17 Nov 2008 11:16:40 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0D73A689E for ; Mon, 17 Nov 2008 11:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjW+JHZwqgnw for ; Mon, 17 Nov 2008 11:16:38 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2CDBC3A69A3 for ; Mon, 17 Nov 2008 11:16:36 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAHJG6gF063183; Tue, 18 Nov 2008 04:16:07 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 18 Nov 2008 04:16:10 +0900 From: Atsushi Kobayashi To: Nevil Brownlee In-Reply-To: <4920A22D.8040303@auckland.ac.nz> References: <4920A22D.8040303@auckland.ac.nz> Message-Id: <20081118030945.E5A5.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Tue, 18 Nov 2008 04:16:08 +0900 (JST) Cc: IPFIX list Subject: Re: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Nevil and all, On Mon, 17 Nov 2008 11:43:57 +1300 Nevil Brownlee wrote: > > Hi all: > > I've at last had time to catch up with the 'Problem Statement' > and 'Framework' drafts for IPFIX mediators. I have a longish > list of 'editorial' suggestions (see below), and one cautious > comment .. Thank you! > > Both these drafts have Informative references to three drafts > (flow anonymisation, aggregation, and flow selection techniques). > But Internet Drafts are "works in progress," and are supposed > to have short lifetimes - which makes them unsuitable as references > in an RFC. > > I agree that all three of these drafts add useful information > to the current Mediators drafts; I wonder whether their 'important > ideas' material could be moved into the Mediators drafts? That > would be better, I feel, than trying to refer to them as Internet > Drafts. Your caution is considered reasonable. But, I have one question. I think that problem statement and framework drafts should not describe detailed functionality related to other drafts to progress them futher. Therefore, I intended to write down the minimum description related to other drafts. Even so, should it add more description? If yes, deriving what are important ideas from specific drafts, and distinguishing the parts that should be moved into Mediator draft needs to be done carefully. It is big task for me and might take time. Please see following text regarding editorial comments. Thanks, Atsushi Kobayashi > > Cheers, Nevil > > > Now for the 'editorial' suggestions: > [ s/old/new/ means "substitute new for old text," > ?? means "if you think this would be better" ] > > > Problem Statement Draft: > > Page 6, definition of IPFIX Mediation > current: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process > suggested: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. IPFIX Mediation can be included in > any IPFIX Devices. IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to ab appropriate > Collecting Process > > current: > * changing a transport protocol which carries IPFIX Messages > suggested: > * changing the transport protocol which carries IPFIX Messages > > Page 7, definition of Flow-Based Collector Selection > current: > Element and then selects Collector for each input Flow Record/ > suggested: > Element and then selects the Collector(s) for each input Flow Record/ > > Page 7, definition of IPFIX Proxy > current: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and convert a legacy protocol message to an IPFIX Message, if > necessary. > suggested: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of an IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > the Message's transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and may convert a legacy protocol message to an IPFIX Message if > necessary. > > Page 8, definition of IPFIX Masquerading Proxy > current: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > suggested: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data in input Flow Records/Packet Reports according to > > Page 9, 3.2 Data Retention > Are there EU standards we could reference to back up this section? Yes. I add EU standard reference. > > Page 10, section 3.4 > current: > Recently, several networks seem to have shifted towards integrated > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to > suggested: > Recently, several networks seem to have shifted towards 'integrated' > technologies such as Internet Protocols and MPLS (which includes > IPv4, IPv6, > and VPN traffic). Flow Records/Packet Reports of these types need to > > current: > identification data, the RD (Route Distinguisher), ingress IF, > suggested: > identification data, the RD (Route Distinguisher), ingress interface, > > Page 12, section 4 > s/networks can even be increased/networks could be increased/ ?? > yes. I feel that it is better than old one. > current: > will increase by approximately 50% per year according to [TRAFGRW]. > suggested: > is likely to increase by approximately 50% per year [TRAFGRW]. > > s\kFlows/s\kFlow/s\ > > Page 13, section 4.2.1 > s/one way to this/one way to do this/ > s/There is an application/Operators could use one application/ > > Page 14: section 4.4 > s/aggregation for one or more/aggregation of one or more/ > > current: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporters. For > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. > o Space Composition within some Exporters > In that case, the spatial range consists of some different > Exporters. For example, the Flow Records observed at same domain, > such as west area and east area of an ISP network, can be composed > to one Flow Records. > suggested: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporter. For > example, the Flow Records observed at physical interfaces which > belong to a virtual interface by link aggregation can be composed > into > one-area Flow Records. > o Space Composition within several Exporters > In that case, the spatial range consists of several different > Exporters. For example, Flow Records observed in the same domain, > such as west area and east area of an ISP network, can be composed > into one-area Flow Records. > > s/exported as merging data/exported as merged data/ > > Page 16, section 5.5 > s/relayed to single/relayed to a single/ > s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ > > > Framework Draft > > Section 2: Check that definitions match those in Problem Statement > after 'editing' changes are made! > > Page 9: s/[*]/[*Applications] ?? Yes. > > Page 10, Figure B: s/Process (es)/Process(es)/ 3 times > Thank you very much. > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 17 11:16:40 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0483A69A3; Mon, 17 Nov 2008 11:16:40 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0D73A689E for ; Mon, 17 Nov 2008 11:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjW+JHZwqgnw for ; Mon, 17 Nov 2008 11:16:38 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 2CDBC3A69A3 for ; Mon, 17 Nov 2008 11:16:36 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAHJG6gF063183; Tue, 18 Nov 2008 04:16:07 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 18 Nov 2008 04:16:10 +0900 From: Atsushi Kobayashi To: Nevil Brownlee In-Reply-To: <4920A22D.8040303@auckland.ac.nz> References: <4920A22D.8040303@auckland.ac.nz> Message-Id: <20081118030945.E5A5.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Tue, 18 Nov 2008 04:16:08 +0900 (JST) Cc: IPFIX list Subject: Re: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Nevil and all, On Mon, 17 Nov 2008 11:43:57 +1300 Nevil Brownlee wrote: > > Hi all: > > I've at last had time to catch up with the 'Problem Statement' > and 'Framework' drafts for IPFIX mediators. I have a longish > list of 'editorial' suggestions (see below), and one cautious > comment .. Thank you! > > Both these drafts have Informative references to three drafts > (flow anonymisation, aggregation, and flow selection techniques). > But Internet Drafts are "works in progress," and are supposed > to have short lifetimes - which makes them unsuitable as references > in an RFC. > > I agree that all three of these drafts add useful information > to the current Mediators drafts; I wonder whether their 'important > ideas' material could be moved into the Mediators drafts? That > would be better, I feel, than trying to refer to them as Internet > Drafts. Your caution is considered reasonable. But, I have one question. I think that problem statement and framework drafts should not describe detailed functionality related to other drafts to progress them futher. Therefore, I intended to write down the minimum description related to other drafts. Even so, should it add more description? If yes, deriving what are important ideas from specific drafts, and distinguishing the parts that should be moved into Mediator draft needs to be done carefully. It is big task for me and might take time. Please see following text regarding editorial comments. Thanks, Atsushi Kobayashi > > Cheers, Nevil > > > Now for the 'editorial' suggestions: > [ s/old/new/ means "substitute new for old text," > ?? means "if you think this would be better" ] > > > Problem Statement Draft: > > Page 6, definition of IPFIX Mediation > current: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process > suggested: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. IPFIX Mediation can be included in > any IPFIX Devices. IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to ab appropriate > Collecting Process > > current: > * changing a transport protocol which carries IPFIX Messages > suggested: > * changing the transport protocol which carries IPFIX Messages > > Page 7, definition of Flow-Based Collector Selection > current: > Element and then selects Collector for each input Flow Record/ > suggested: > Element and then selects the Collector(s) for each input Flow Record/ > > Page 7, definition of IPFIX Proxy > current: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and convert a legacy protocol message to an IPFIX Message, if > necessary. > suggested: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of an IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > the Message's transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and may convert a legacy protocol message to an IPFIX Message if > necessary. > > Page 8, definition of IPFIX Masquerading Proxy > current: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > suggested: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data in input Flow Records/Packet Reports according to > > Page 9, 3.2 Data Retention > Are there EU standards we could reference to back up this section? Yes. I add EU standard reference. > > Page 10, section 3.4 > current: > Recently, several networks seem to have shifted towards integrated > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to > suggested: > Recently, several networks seem to have shifted towards 'integrated' > technologies such as Internet Protocols and MPLS (which includes > IPv4, IPv6, > and VPN traffic). Flow Records/Packet Reports of these types need to > > current: > identification data, the RD (Route Distinguisher), ingress IF, > suggested: > identification data, the RD (Route Distinguisher), ingress interface, > > Page 12, section 4 > s/networks can even be increased/networks could be increased/ ?? > yes. I feel that it is better than old one. > current: > will increase by approximately 50% per year according to [TRAFGRW]. > suggested: > is likely to increase by approximately 50% per year [TRAFGRW]. > > s\kFlows/s\kFlow/s\ > > Page 13, section 4.2.1 > s/one way to this/one way to do this/ > s/There is an application/Operators could use one application/ > > Page 14: section 4.4 > s/aggregation for one or more/aggregation of one or more/ > > current: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporters. For > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. > o Space Composition within some Exporters > In that case, the spatial range consists of some different > Exporters. For example, the Flow Records observed at same domain, > such as west area and east area of an ISP network, can be composed > to one Flow Records. > suggested: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporter. For > example, the Flow Records observed at physical interfaces which > belong to a virtual interface by link aggregation can be composed > into > one-area Flow Records. > o Space Composition within several Exporters > In that case, the spatial range consists of several different > Exporters. For example, Flow Records observed in the same domain, > such as west area and east area of an ISP network, can be composed > into one-area Flow Records. > > s/exported as merging data/exported as merged data/ > > Page 16, section 5.5 > s/relayed to single/relayed to a single/ > s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ > > > Framework Draft > > Section 2: Check that definitions match those in Problem Statement > after 'editing' changes are made! > > Page 9: s/[*]/[*Applications] ?? Yes. > > Page 10, Figure B: s/Process (es)/Process(es)/ 3 times > Thank you very much. > -- > --------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 18 07:58:56 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D843A6961; Tue, 18 Nov 2008 07:58:55 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49AE3A6961 for ; Tue, 18 Nov 2008 07:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5csOUSNjZJQN for ; Tue, 18 Nov 2008 07:58:54 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id EC8333A6851 for ; Tue, 18 Nov 2008 07:58:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B646C9E142 for ; Wed, 19 Nov 2008 04:58:50 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U3wT+oLZN5N for ; Wed, 19 Nov 2008 04:58:50 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 32E0F9E0EF for ; Wed, 19 Nov 2008 04:58:47 +1300 (NZDT) Message-ID: <4922E630.20608@auckland.ac.nz> Date: Wed, 19 Nov 2008 04:58:40 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Slides for IPFIX meeting tomorrow X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put the meeting slides I've received so far on the Meeting Materials page, you can see them at https://datatracker.ietf.org/meeting/73/materials.html If you have slides to present, please email them to me real soon now. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 18 07:58:56 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D843A6961; Tue, 18 Nov 2008 07:58:55 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49AE3A6961 for ; Tue, 18 Nov 2008 07:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5csOUSNjZJQN for ; Tue, 18 Nov 2008 07:58:54 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id EC8333A6851 for ; Tue, 18 Nov 2008 07:58:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id B646C9E142 for ; Wed, 19 Nov 2008 04:58:50 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U3wT+oLZN5N for ; Wed, 19 Nov 2008 04:58:50 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 32E0F9E0EF for ; Wed, 19 Nov 2008 04:58:47 +1300 (NZDT) Message-ID: <4922E630.20608@auckland.ac.nz> Date: Wed, 19 Nov 2008 04:58:40 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] Slides for IPFIX meeting tomorrow X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: I've put the meeting slides I've received so far on the Meeting Materials page, you can see them at https://datatracker.ietf.org/meeting/73/materials.html If you have slides to present, please email them to me real soon now. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 18 15:17:52 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE2E28C16A; Tue, 18 Nov 2008 15:17:52 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DC63A68EF; Tue, 18 Nov 2008 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkiPNR2x4l7p; Tue, 18 Nov 2008 15:17:50 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 227EB3A6869; Tue, 18 Nov 2008 15:17:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220241600"; d="scan'208";a="151565016" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Nov 2008 18:17:48 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Nov 2008 18:17:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:17:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard Thread-Index: AclJurvVpgb8kxaiQdW4/iNaOUP1NQAE6aGQ From: "Romascanu, Dan (Dan)" To: Cc: ipfix@ietf.org Subject: [IPFIX] FW: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Congratulations to the editors, chair and the whole working group for achieving this milestone. No less than other seven documents in psamp and ipfix had dependencies on this I-D! Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, November 18, 2008 10:17 PM To: IETF-Announce Cc: psamp chair; Internet Architecture Board; psamp mailing list; RFC Editor Subject: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard The IESG has approved the following document: - 'Information Model for Packet Sampling Exports ' as a Proposed Standard This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-11.txt Technical Summary This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. Working Group Summary There is consensus From ipfix-bounces@ietf.org Tue Nov 18 15:17:52 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE2E28C16A; Tue, 18 Nov 2008 15:17:52 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DC63A68EF; Tue, 18 Nov 2008 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkiPNR2x4l7p; Tue, 18 Nov 2008 15:17:50 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 227EB3A6869; Tue, 18 Nov 2008 15:17:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,627,1220241600"; d="scan'208";a="151565016" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Nov 2008 18:17:48 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Nov 2008 18:17:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 00:17:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard Thread-Index: AclJurvVpgb8kxaiQdW4/iNaOUP1NQAE6aGQ From: "Romascanu, Dan (Dan)" To: Cc: ipfix@ietf.org Subject: [IPFIX] FW: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Congratulations to the editors, chair and the whole working group for achieving this milestone. No less than other seven documents in psamp and ipfix had dependencies on this I-D! Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, November 18, 2008 10:17 PM To: IETF-Announce Cc: psamp chair; Internet Architecture Board; psamp mailing list; RFC Editor Subject: Protocol Action: 'Information Model for Packet Sampling Exports' to Proposed Standard The IESG has approved the following document: - 'Information Model for Packet Sampling Exports ' as a Proposed Standard This document is the product of the Packet Sampling Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-11.txt Technical Summary This memo defines an information model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IPFIX protocol, this information model is an extension to the IPFIX information model. Working Group Summary There is consensus inin the WG to publish these documents. Document Quality Several of the Information Elements defined in this document have already been implemented by academic as well as industrial institutions, but not all of them have been implemented and tested, yet. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. Juergen Quittek will be the principal expert for the selectorAlgorithm registry working with IANA. RFC Editor Note 1. Insert in section 1, after the second paragraph the following paragraph: NEW: Although the PSAMP charter specified no requirements for measuring packet errors (such as drops, malformed, etc.), and this draft does not cover such data, if there is need for collecting and exporting packet error information, the appropriate Information Elements can be requested from IANA, and exported with the PSAMP protocol. 2. in Section 8.2.4. samplingTimeInterval OLD: Abstract Data Type: dateTimeMicroseconds NEW: Abstract Data Type: unsigned32 3. in Section 8.2.5. samplingTimeSpace OLD: Abstract Data Type: dateTimeMicroseconds NEW: Abstract Data Type: unsigned32 4. in section 8.5.1. ipHeaderPacketSection Delete: Data Type Semantics: quantity 5. in section 8.5.2. ipPayloadPacketSection Delete: Data Type Semantics: quantity 6. in section 8.5.3. mplsLabelStackSection Delete: Data Type Semantics: quantity 7. in section 8.5.4. mplsPayloadPacketSection Delete: Data Type Semantics: quantity 8. in Appendix A.: Delete: Using XML-based specifications does not currently address possible IANA implications associated with XML Namespace URIs. The use of Namespaces as an extension mechanism implies that an IANA registered Namespace URI should be available and that directory names below this base URI be assigned for relevant IETF specifications. The authors are not aware of this mechanism today. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix the WG to publish these documents. Document Quality Several of the Information Elements defined in this document have already been implemented by academic as well as industrial institutions, but not all of them have been implemented and tested, yet. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. Juergen Quittek will be the principal expert for the selectorAlgorithm registry working with IANA. RFC Editor Note 1. Insert in section 1, after the second paragraph the following paragraph: NEW: Although the PSAMP charter specified no requirements for measuring packet errors (such as drops, malformed, etc.), and this draft does not cover such data, if there is need for collecting and exporting packet error information, the appropriate Information Elements can be requested from IANA, and exported with the PSAMP protocol. 2. in Section 8.2.4. samplingTimeInterval OLD: Abstract Data Type: dateTimeMicroseconds NEW: Abstract Data Type: unsigned32 3. in Section 8.2.5. samplingTimeSpace OLD: Abstract Data Type: dateTimeMicroseconds NEW: Abstract Data Type: unsigned32 4. in section 8.5.1. ipHeaderPacketSection Delete: Data Type Semantics: quantity 5. in section 8.5.2. ipPayloadPacketSection Delete: Data Type Semantics: quantity 6. in section 8.5.3. mplsLabelStackSection Delete: Data Type Semantics: quantity 7. in section 8.5.4. mplsPayloadPacketSection Delete: Data Type Semantics: quantity 8. in Appendix A.: Delete: Using XML-based specifications does not currently address possible IANA implications associated with XML Namespace URIs. The use of Namespaces as an extension mechanism implies that an IANA registered Namespace URI should be available and that directory names below this base URI be assigned for relevant IETF specifications. The authors are not aware of this mechanism today. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 18 16:29:48 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD27C3A6B0C; Tue, 18 Nov 2008 16:29:48 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4173A6B0C for ; Tue, 18 Nov 2008 16:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j-vyWBl2w28 for ; Tue, 18 Nov 2008 16:29:46 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D6FFF3A6947 for ; Tue, 18 Nov 2008 16:29:45 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAJ0Tid29262; Wed, 19 Nov 2008 01:29:44 +0100 (CET) Received: from [10.61.71.117] (ams3-vpn-dhcp1909.cisco.com [10.61.71.117]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAJ0TfG29206; Wed, 19 Nov 2008 01:29:43 +0100 (CET) Message-ID: <49235DF4.5020008@cisco.com> Date: Tue, 18 Nov 2008 18:29:40 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nevil Brownlee References: <4920A22D.8040303@auckland.ac.nz> In-Reply-To: <4920A22D.8040303@auckland.ac.nz> Cc: IPFIX list Subject: Re: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Nevil, > > Hi all: > > I've at last had time to catch up with the 'Problem Statement' > and 'Framework' drafts for IPFIX mediators. I have a longish > list of 'editorial' suggestions (see below), and one cautious > comment .. > > Both these drafts have Informative references to three drafts > (flow anonymisation, aggregation, and flow selection techniques). > But Internet Drafts are "works in progress," and are supposed > to have short lifetimes - which makes them unsuitable as references > in an RFC. Agreed that this is an issue, and that the references should be removed. > > I agree that all three of these drafts add useful information > to the current Mediators drafts; I wonder whether their 'important > ideas' material could be moved into the Mediators drafts? That > would be better, I feel, than trying to refer to them as Internet > Drafts. The mediation framework draft mentions the notion of "intermediate process." If there is something to be standardized in the three different domains, then the three drafts should reference the intermediate process. In other words, build on the framework draft. Regards, Benoit. > > Cheers, Nevil > > > Now for the 'editorial' suggestions: > [ s/old/new/ means "substitute new for old text," > ?? means "if you think this would be better" ] > > > Problem Statement Draft: > > Page 6, definition of IPFIX Mediation > current: > IPFIX Mediation is a function located betweenFrom ipfix-bounces@ietf.org Tue Nov 18 16:29:48 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD27C3A6B0C; Tue, 18 Nov 2008 16:29:48 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4173A6B0C for ; Tue, 18 Nov 2008 16:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j-vyWBl2w28 for ; Tue, 18 Nov 2008 16:29:46 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D6FFF3A6947 for ; Tue, 18 Nov 2008 16:29:45 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAJ0Tid29262; Wed, 19 Nov 2008 01:29:44 +0100 (CET) Received: from [10.61.71.117] (ams3-vpn-dhcp1909.cisco.com [10.61.71.117]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAJ0TfG29206; Wed, 19 Nov 2008 01:29:43 +0100 (CET) Message-ID: <49235DF4.5020008@cisco.com> Date: Tue, 18 Nov 2008 18:29:40 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Nevil Brownlee References: <4920A22D.8040303@auckland.ac.nz> In-Reply-To: <4920A22D.8040303@auckland.ac.nz> Cc: IPFIX list Subject: Re: [IPFIX] Comments/suggestions on IPFIX Mediators Drafts -01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Nevil, > > Hi all: > > I've at last had time to catch up with the 'Problem Statement' > and 'Framework' drafts for IPFIX mediators. I have a longish > list of 'editorial' suggestions (see below), and one cautious > comment .. > > Both these drafts have Informative references to three drafts > (flow anonymisation, aggregation, and flow selection techniques). > But Internet Drafts are "works in progress," and are supposed > to have short lifetimes - which makes them unsuitable as references > in an RFC. Agreed that this is an issue, and that the references should be removed. > > I agree that all three of these drafts add useful information > to the current Mediators drafts; I wonder whether their 'important > ideas' material could be moved into the Mediators drafts? That > would be better, I feel, than trying to refer to them as Internet > Drafts. The mediation framework draft mentions the notion of "intermediate process." If there is something to be standardized in the three different domains, then the three drafts should reference the intermediate process. In other words, build on the framework draft. Regards, Benoit. > > Cheers, Nevil > > > Now for the 'editorial' suggestions: > [ s/old/new/ means "substitute new for old text," > ?? means "if you think this would be better" ] > > > Problem Statement Draft: > > Page 6, definition of IPFIX Mediation > current: > IPFIX Mediation is a function located betwe Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process > suggested: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. IPFIX Mediation can be included in > any IPFIX Devices. IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to ab appropriate > Collecting Process > > current: > * changing a transport protocol which carries IPFIX Messages > suggested: > * changing the transport protocol which carries IPFIX Messages > > Page 7, definition of Flow-Based Collector Selection > current: > Element and then selects Collector for each input Flow Record/ > suggested: > Element and then selects the Collector(s) for each input Flow > Record/ > > Page 7, definition of IPFIX Proxy > current: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and convert a legacy protocol message to an IPFIX Message, if > necessary. > suggested: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of an IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > the Message's transport protocol, such as UDP, TCP, SCTP and > PR-SCTP, > and may convert a legacy protocol message to an IPFIX Message if > necessary. > > Page 8, definition of IPFIX Masquerading Proxy > current: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > suggested: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data in input Flow Records/Packet Reports > according to > > Page 9, 3.2 Data Retention > Are there EU standards we could reference to back up this section? > > Page 10, section 3.4 > current: > Recently, several networks seem to have shifted towards integrated > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to > suggested: > Recently, several networks seem to have shifted towards 'integrated' > technologies such as Internet Protocols and MPLS (which includes > IPv4, IPv6, > and VPN traffic). Flow Records/Packet Reports of these types need to > > current: > identification data, the RD (Route Distinguisher), ingress IF, > suggested: > identification data, the RD (Route Distinguisher), ingress interface, > > Page 12, section 4 > s/networks can even be increased/networks could be increased/ ?? > > current: > will increase by approximately 50% per year according to [TRAFGRW]. > suggested: > is likely to increase by approximately 50% per year [TRAFGRW]. > > s\kFlows/s\kFlow/s\ > > Page 13, section 4.2.1 > s/one way to this/one way to do this/ > s/There is an application/Operators could use one application/ > > Page 14: section 4.4 > s/aggregation for one or more/aggregation of one or more/ > > current: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporters. For > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. > o Space Composition within some Exporters > In that case, the spen Exporting Processes > and Collecting Processes. The IPFIX Mediation can be included in > any IPFIX Devices. The IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to a appropriate > Collecting Process > suggested: > IPFIX Mediation is a function located between Exporting Processes > and Collecting Processes. IPFIX Mediation can be included in > any IPFIX Devices. IPFIX Mediation consists of a set of some > of functions: > > * rerouting input Flow Records/Packet Reports to ab appropriate > Collecting Process > > current: > * changing a transport protocol which carries IPFIX Messages > suggested: > * changing the transport protocol which carries IPFIX Messages > > Page 7, definition of Flow-Based Collector Selection > current: > Element and then selects Collector for each input Flow Record/ > suggested: > Element and then selects the Collector(s) for each input Flow > Record/ > > Page 7, definition of IPFIX Proxy > current: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > and convert a legacy protocol message to an IPFIX Message, if > necessary. > suggested: > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > from an Original Exporter, and sends IPFIX Messages to one or more > Collectors. It may alter a part of an IPFIX Message in order to > comply with IPFIX Protocol specifications. It may also change > the Message's transport protocol, such as UDP, TCP, SCTP and > PR-SCTP, > and may convert a legacy protocol message to an IPFIX Message if > necessary. > > Page 8, definition of IPFIX Masquerading Proxy > current: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of data of input Flow Records/Packet Reports according to > suggested: > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > a part of the data in input Flow Records/Packet Reports > according to > > Page 9, 3.2 Data Retention > Are there EU standards we could reference to back up this section? > > Page 10, section 3.4 > current: > Recently, several networks seem to have shifted towards integrated > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > and VPN traffic. Flow Records/Packet Reports of these types need to > suggested: > Recently, several networks seem to have shifted towards 'integrated' > technologies such as Internet Protocols and MPLS (which includes > IPv4, IPv6, > and VPN traffic). Flow Records/Packet Reports of these types need to > > current: > identification data, the RD (Route Distinguisher), ingress IF, > suggested: > identification data, the RD (Route Distinguisher), ingress interface, > > Page 12, section 4 > s/networks can even be increased/networks could be increased/ ?? > > current: > will increase by approximately 50% per year according to [TRAFGRW]. > suggested: > is likely to increase by approximately 50% per year [TRAFGRW]. > > s\kFlows/s\kFlow/s\ > > Page 13, section 4.2.1 > s/one way to this/one way to do this/ > s/There is an application/Operators could use one application/ > > Page 14: section 4.4 > s/aggregation for one or more/aggregation of one or more/ > > current: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporters. For > example, the Flow Records observed at physical interfaces which > belong to virtual interface by link aggregation can be composed to > one Flow Records. > o Space Composition within some Exporters > In that case, the atial range consists of some different > Exporters. For example, the Flow Records observed at same domain, > such as west area and east area of an ISP network, can be composed > to one Flow Records. > suggested: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporter. For > example, the Flow Records observed at physical interfaces which > belong to a virtual interface by link aggregation can be > composed into > one-area Flow Records. > o Space Composition within several Exporters > In that case, the spatial range consists of several different > Exporters. For example, Flow Records observed in the same domain, > such as west area and east area of an ISP network, can be composed > into one-area Flow Records. > > s/exported as merging data/exported as merged data/ > > Page 16, section 5.5 > s/relayed to single/relayed to a single/ > s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ > > > Framework Draft > > Section 2: Check that definitions match those in Problem Statement > after 'editing' changes are made! > > Page 9: s/[*]/[*Applications] ?? > > Page 10, Figure B: s/Process (es)/Process(es)/ 3 times > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix spatial range consists of some different > Exporters. For example, the Flow Records observed at same domain, > such as west area and east area of an ISP network, can be composed > to one Flow Records. > suggested: > o Space Composition within one Exporter > In that case, the spatial range is within one Exporter. For > example, the Flow Records observed at physical interfaces which > belong to a virtual interface by link aggregation can be > composed into > one-area Flow Records. > o Space Composition within several Exporters > In that case, the spatial range consists of several different > Exporters. For example, Flow Records observed in the same domain, > such as west area and east area of an ISP network, can be composed > into one-area Flow Records. > > s/exported as merging data/exported as merged data/ > > Page 16, section 5.5 > s/relayed to single/relayed to a single/ > s/IPFIX Mediators shuts down/IPFIX Mediator shuts down/ > > > Framework Draft > > Section 2: Check that definitions match those in Problem Statement > after 'editing' changes are made! > > Page 9: s/[*]/[*Applications] ?? > > Page 10, Figure B: s/Process (es)/Process(es)/ 3 times > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 18 23:22:56 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D583A6A30; Tue, 18 Nov 2008 23:22:56 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB42B3A6A30 for ; Tue, 18 Nov 2008 23:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDWP9r4g6Rgs for ; Tue, 18 Nov 2008 23:22:51 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A1D7C3A63EC for ; Tue, 18 Nov 2008 23:22:49 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAJ7MdxB087887; Wed, 19 Nov 2008 16:22:44 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 19 Nov 2008 16:22:47 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492150CD.4040101@net.in.tum.de> References: <492150CD.4040101@net.in.tum.de> Message-Id: <20081119003311.E5B7.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Wed, 19 Nov 2008 16:22:46 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Gerhard, Thank you for valuable comments. On Mon, 17 Nov 2008 12:09:01 +0100 Gerhard Muenz wrote: > > Dear Atsushi, all, > > I reviewed the mediator problem statement draft. > > For me, the purpose of the draft is not quite clear. Is it to justify > the need of IPFIX Mediators? Then, the focus should be more on > monitoring situations that cannot be adequately handled without this > intermediate box between exporters and collectors. > This draft covers the possible examples related to Mediation, and some problems that IPFIX mediator will face in future. For me, some of applicable examples shows vital function, such as "IPFIX Export Across Domains" or "Interoperability between Legacy Protocols and IPFIX". I think that it is better to gather other applicable examples than focusing on vital functions in order to show the effectiveness of mediator. So, I am wondering if some applicable examples should be removed or if other more vital examples should be added. What do you think? > If functionalities like configurable flow keys, flow selection, > anonymization are realized on an IPFIX exporter directly, they can be > considered as part of the Metering Process. So, there is no mediation > involved. > Certainly, some of mediation function can be considered as part of Metering Process. But, maintaining Flow Records is main task of Metering Process. Other functions, such as anonymization or flow selection, are not limited to be iFrom ipfix-bounces@ietf.org Tue Nov 18 23:22:56 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D583A6A30; Tue, 18 Nov 2008 23:22:56 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB42B3A6A30 for ; Tue, 18 Nov 2008 23:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDWP9r4g6Rgs for ; Tue, 18 Nov 2008 23:22:51 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id A1D7C3A63EC for ; Tue, 18 Nov 2008 23:22:49 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAJ7MdxB087887; Wed, 19 Nov 2008 16:22:44 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 19 Nov 2008 16:22:47 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492150CD.4040101@net.in.tum.de> References: <492150CD.4040101@net.in.tum.de> Message-Id: <20081119003311.E5B7.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Wed, 19 Nov 2008 16:22:46 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Gerhard, Thank you for valuable comments. On Mon, 17 Nov 2008 12:09:01 +0100 Gerhard Muenz wrote: > > Dear Atsushi, all, > > I reviewed the mediator problem statement draft. > > For me, the purpose of the draft is not quite clear. Is it to justify > the need of IPFIX Mediators? Then, the focus should be more on > monitoring situations that cannot be adequately handled without this > intermediate box between exporters and collectors. > This draft covers the possible examples related to Mediation, and some problems that IPFIX mediator will face in future. For me, some of applicable examples shows vital function, such as "IPFIX Export Across Domains" or "Interoperability between Legacy Protocols and IPFIX". I think that it is better to gather other applicable examples than focusing on vital functions in order to show the effectiveness of mediator. So, I am wondering if some applicable examples should be removed or if other more vital examples should be added. What do you think? > If functionalities like configurable flow keys, flow selection, > anonymization are realized on an IPFIX exporter directly, they can be > considered as part of the Metering Process. So, there is no mediation > involved. > Certainly, some of mediation function can be considered as part of Metering Process. But, maintaining Flow Records is main task of Metering Process. Other functions, such as anonymization or flow selection, are not limited to bencluded in Metering Process. For example, I can think that the general Metering Process in interface module can create Flow Records, and then Mediation in main cpu module can anonymize them. Therefore, locating "mediation" in any devices can be utilized. Please see following text regarding other comments. Regards, Atsushi KOBAYASHI > Therefore, I would restrict the usage of the term "mediation" to the > IPFIX mediator case. > > Regards, > Gerhard > > > > Abstract > > > > Flow-based measurement is currently a popular method for various > > Remove "currently". We should assume that this is also valid in future. > Yes. > > network monitoring usages. The sharing of flow-based information > > among orthogonal monitoring applications raises open issues in terms > > not sure what you mean by "orthogonal" > The requirement of several applications in same network could be orthogonal as following. - Granularity of Flow Records: coarse-grained or fine-grained. - Time of period for storage: long-term or short-term. - Traceability: anonymization or not. These situation could not be compatible without mediation. I will consider more about this sentence. > > of scalability, reliability and flexibility that IPFIX Mediation may > > help resolve. IPFIX Mediation reroutes, replicates, filters, > > aggregates, correlates or modifies Flow Records or Packet Reports, or > > changes a transport protocol. This document describes the > > You could introduce more clearly two classes of mediation: > - mediation of content which changes the information, e.g. sampling, > filtering, aggregation, anonymization,... > - mediation of IPFIX transport which does not affect the information, > e.g. rerouting, replication, changing the transport protocol etc. > (storage would also fall into this category) > Thank you your suggestion. I will improve abstract in your points. > > applicability of IPFIX Mediation and the problems that IPFIX > > Mediation might encounter. > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology and Definition . . . . . . . . . . . . . . . . . . 4 > > 3. Flow-Based Mediation: Applicability Examples . . . . . . . . . 9 > > 3.1. IPFIX Export Across Domains . . . . . . . . . . . . . . . 9 > > 3.2. Data Retention . . . . . . . . . . . . . . . . . . . . . . 9 > > 3.3. Interoperability between Legacy Protocols and IPFIX . . . 9 > > 3.4. Rerouting Flow Records/Packet Reports . . . . . . . . . . 10 > > 3.5. IPFIX Export from Branch Office . . . . . . . . . . . . . 10 > > 3.6. Correlation of Flow Records/Packet Reports Information . . 11 > > 4. Approaches to Scalability . . . . . . . . . . . . . . . . . . 12 > > 4.1. Adjusting Sampling Rates . . . . . . . . . . . . . . . . . 12 > > 4.2. Flow Aggregation . . . . . . . . . . . . . . . . . . . . . 12 > > 4.2.1. Flow Aggregation on Original Exporters . . . . . . . . 13 > > 4.2.2. Flow Aggregation on IPFIX Concentrators . . . . . . . 13 > > 4.3. Time Composition . . . . . . . . . . . . . . . . . . . . . 13 > > 4.4. Space Composition . . . . . . . . . . . . . . . . . . . . 14 > > 4.5. Distributing Load among Collectors . . . . . . . . . . . . 14 > > 4.6. Flow Selection Sampling . . . . . . . . . . . . . . . . . 14 > > 5. Problems with using IPFIX Mediators . . . . . . . . . . . . . 15 > > 5.1. Loss of Observation Point Information . . . . . . . . . . 15 > > 5.2. Loss of Base Time Information . . . . . . . . . . . . . . 16 > > 5.3. Loss of Option Template Information . . . . . . . . . . . 16 > > 5.4. Observation Domain ID and Template ID Management . . . . . 16 > > 5.5. Transport Sessions Management . . . . . . . . . . . . . . 16 > > 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > > 8. IANA Considerations . . . . . . . included in Metering Process. For example, I can think that the general Metering Process in interface module can create Flow Records, and then Mediation in main cpu module can anonymize them. Therefore, locating "mediation" in any devices can be utilized. Please see following text regarding other comments. Regards, Atsushi KOBAYASHI > Therefore, I would restrict the usage of the term "mediation" to the > IPFIX mediator case. > > Regards, > Gerhard > > > > Abstract > > > > Flow-based measurement is currently a popular method for various > > Remove "currently". We should assume that this is also valid in future. > Yes. > > network monitoring usages. The sharing of flow-based information > > among orthogonal monitoring applications raises open issues in terms > > not sure what you mean by "orthogonal" > The requirement of several applications in same network could be orthogonal as following. - Granularity of Flow Records: coarse-grained or fine-grained. - Time of period for storage: long-term or short-term. - Traceability: anonymization or not. These situation could not be compatible without mediation. I will consider more about this sentence. > > of scalability, reliability and flexibility that IPFIX Mediation may > > help resolve. IPFIX Mediation reroutes, replicates, filters, > > aggregates, correlates or modifies Flow Records or Packet Reports, or > > changes a transport protocol. This document describes the > > You could introduce more clearly two classes of mediation: > - mediation of content which changes the information, e.g. sampling, > filtering, aggregation, anonymization,... > - mediation of IPFIX transport which does not affect the information, > e.g. rerouting, replication, changing the transport protocol etc. > (storage would also fall into this category) > Thank you your suggestion. I will improve abstract in your points. > > applicability of IPFIX Mediation and the problems that IPFIX > > Mediation might encounter. > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology and Definition . . . . . . . . . . . . . . . . . . 4 > > 3. Flow-Based Mediation: Applicability Examples . . . . . . . . . 9 > > 3.1. IPFIX Export Across Domains . . . . . . . . . . . . . . . 9 > > 3.2. Data Retention . . . . . . . . . . . . . . . . . . . . . . 9 > > 3.3. Interoperability between Legacy Protocols and IPFIX . . . 9 > > 3.4. Rerouting Flow Records/Packet Reports . . . . . . . . . . 10 > > 3.5. IPFIX Export from Branch Office . . . . . . . . . . . . . 10 > > 3.6. Correlation of Flow Records/Packet Reports Information . . 11 > > 4. Approaches to Scalability . . . . . . . . . . . . . . . . . . 12 > > 4.1. Adjusting Sampling Rates . . . . . . . . . . . . . . . . . 12 > > 4.2. Flow Aggregation . . . . . . . . . . . . . . . . . . . . . 12 > > 4.2.1. Flow Aggregation on Original Exporters . . . . . . . . 13 > > 4.2.2. Flow Aggregation on IPFIX Concentrators . . . . . . . 13 > > 4.3. Time Composition . . . . . . . . . . . . . . . . . . . . . 13 > > 4.4. Space Composition . . . . . . . . . . . . . . . . . . . . 14 > > 4.5. Distributing Load among Collectors . . . . . . . . . . . . 14 > > 4.6. Flow Selection Sampling . . . . . . . . . . . . . . . . . 14 > > 5. Problems with using IPFIX Mediators . . . . . . . . . . . . . 15 > > 5.1. Loss of Observation Point Information . . . . . . . . . . 15 > > 5.2. Loss of Base Time Information . . . . . . . . . . . . . . 16 > > 5.3. Loss of Option Template Information . . . . . . . . . . . 16 > > 5.4. Observation Domain ID and Template ID Management . . . . . 16 > > 5.5. Transport Sessions Management . . . . . . . . . . . . . . 16 > > 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 > > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > > 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 > > Intellectual Property and Copyright Statements . . . . . . . . . . 25 > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 2] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 1. Introduction > > > > > > While the IPFIX requirements defined in [RFC3917] mention an > > intermediate function, such as an IPFIX Proxy or an Concentrator, > > "...mention intermediate functions, such as IPFIX proxies and IPFIX > concentrators [not sure if these terms should start with capital > letters],..." > Do you mean the capital letters are not allowed to be used before terminology section? > > there is no document to define the function called IPFIX Mediation. > > IPFIX Mediation is an additional function to suit the needs of some > > measurement system. In this document, we describe several applicable > > Isn't IPFIX Mediation supposed to be an umbrella term which includes > IPFIX concentrators and IPFIX proxies? > I mean that IPFIX Mediator is umbrella term which includes IPFIX concentrators and IPFIX proxies. But, IPFIX Mediation is not. I will improve sentences. > > examples of IPFIX Mediation. Furthermore, we describe the problems > > of IPFIX Mediation considering implementations. These problems can > > be solved by additional specifications without influencing the > > present IPFIX specification defined in [RFC5101]. > > "IPFIX protocol specification" > Yes. > > Section 2 describes the terminology used in this document. Section 3 > > describes applicable examples of IPFIX Mediation. As more effective > > cases, section 4 describes some usages of the IPFIX Mediation in > > large-scale networks. Finally, section 5 describes the problems an > > implementation of an IPFIX Mediation device might face. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 3] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 2. Terminology and Definition > > > > > > The terms in this section are in line with those in the IPFIX > > specification document [RFC5101] and the PSAMP specification document > > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > > What do you mean by "inline"? > If you reuse terms from RFC5101, then you do not have to repeat them > here. Only additional terms should appear in this section. Otherwise it > is not clear which terms are new. > At first, I added terms from RFC5101 to make it easy-to-understand for first IPFIX reader. But, it does not clear whether there is a difference between original term, even if same. I will improve the following description. Flow Key [RFC5101] Flow Record [RFC5101] Observation Point [RFC5101] Exporter [RFC5101] Collector [RFC5101] > > Mediation are also defined here. All these terms are capitalized in > > this document. > > > > Observation Point > > > > An Observation Point is a location in the network where IP packets > > can be observed. Examples include: a line to which a probe is > > attached, a shared medium, such as an Ethernet-based LAN, a single > > port of a router, or a set of interfaces (physical or logical) of > > a router. > > > > Note that every Observation Point is associated with an > > Observation Domain (defined below), and that one Observation Point > > may be a superset o . . . . . . . . . . . . . . . 21 > > 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > > 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > > 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 > > Intellectual Property and Copyright Statements . . . . . . . . . . 25 > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 2] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 1. Introduction > > > > > > While the IPFIX requirements defined in [RFC3917] mention an > > intermediate function, such as an IPFIX Proxy or an Concentrator, > > "...mention intermediate functions, such as IPFIX proxies and IPFIX > concentrators [not sure if these terms should start with capital > letters],..." > Do you mean the capital letters are not allowed to be used before terminology section? > > there is no document to define the function called IPFIX Mediation. > > IPFIX Mediation is an additional function to suit the needs of some > > measurement system. In this document, we describe several applicable > > Isn't IPFIX Mediation supposed to be an umbrella term which includes > IPFIX concentrators and IPFIX proxies? > I mean that IPFIX Mediator is umbrella term which includes IPFIX concentrators and IPFIX proxies. But, IPFIX Mediation is not. I will improve sentences. > > examples of IPFIX Mediation. Furthermore, we describe the problems > > of IPFIX Mediation considering implementations. These problems can > > be solved by additional specifications without influencing the > > present IPFIX specification defined in [RFC5101]. > > "IPFIX protocol specification" > Yes. > > Section 2 describes the terminology used in this document. Section 3 > > describes applicable examples of IPFIX Mediation. As more effective > > cases, section 4 describes some usages of the IPFIX Mediation in > > large-scale networks. Finally, section 5 describes the problems an > > implementation of an IPFIX Mediation device might face. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 3] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 2. Terminology and Definition > > > > > > The terms in this section are in line with those in the IPFIX > > specification document [RFC5101] and the PSAMP specification document > > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > > What do you mean by "inline"? > If you reuse terms from RFC5101, then you do not have to repeat them > here. Only additional terms should appear in this section. Otherwise it > is not clear which terms are new. > At first, I added terms from RFC5101 to make it easy-to-understand for first IPFIX reader. But, it does not clear whether there is a difference between original term, even if same. I will improve the following description. Flow Key [RFC5101] Flow Record [RFC5101] Observation Point [RFC5101] Exporter [RFC5101] Collector [RFC5101] > > Mediation are also defined here. All these terms are capitalized in > > this document. > > > > Observation Point > > > > An Observation Point is a location in the network where IP packets > > can be observed. Examples include: a line to which a probe is > > attached, a shared medium, such as an Ethernet-based LAN, a single > > port of a router, or a set of interfaces (physical or logical) of > > a router. > > > > Note that every Observation Point is associated with an > > Observation Domain (defined below), and that one Observation Point > > may be a supersetf several other Observation Points. For > > example, one Observation Point can be an entire line card. That > > would be the superset of the individual Observation Points at the > > line card's interfaces. > > > > Observation Domain > > > > An Observation Domain is the largest set of Observation Points for > > which Flow information can be aggregated by a Metering Process. > > For example, a router line card may be an Observation Domain if it > > is composed of several interfaces, each of which is an Observation > > Point. In the IPFIX Message it generates, the Observation Domain > > includes its Observation Domain ID, which is unique per Exporting > > Process. That way, the Collecting Process can identify the > > specific Observation Domain from the Exporter that sends the IPFIX > > Messages. Every Observation Point is associated with an > > Observation Domain. It is RECOMMENDED that Observation Domain IDs > > also be unique per IPFIX Device. > > > > Flow Key > > > > Each of the fields that: > > > > 1. belong to the packet header (e.g., destination IP address), > > > > 2. are a property of the packet itself (e.g., packet length), > > > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > > number), > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 4] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > and that are used to define a Flow are termed Flow Keys. > > > > Flow Record > > > > A Flow Record contains information about a specific Flow that was > > observed at an Observation Point. A Flow Record contains measured > > properties of the Flow (e.g., the total number of bytes for all > > the Flow's packets) and usually characteristic properties of the > > Flow (e.g., source IP address). > > > > Packet Reports > > > > Packet Reports comprise a configurable subset of a packet's input > > to the Selection Process, including the Packet Content, > > information relating to its treatment (for example, the output > > interface), and its associated selection state (for example, a > > hash of the Packet Content). > > > > Exporting Process > > > > The Exporting Process sends Flow Records to one or more Collecting > > Processes. The Flow Records are generated by one or more Metering > > Processes. > > > > Exporter > > > > A device that hosts one or more Exporting Processes is termed an > > Exporter. > > > > IPFIX Device > > > > An IPFIX Device hosts at least one Exporting Process. It may host > > further Exporting Processes and arbitrary numbers of Observation > > Points and Metering Processes. > > > > Collecting Process > > > > A Collecting Process receives Flow Records from one or more > > Exporting Processes. The Collecting Process might process or > > store received Flow Records, but such actions are out of scope for > > this document. > > > > Collector > > > > A device that hosts one or more Collecting Processes is termed a > > Collector. > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 5] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > IPFIX Message > > > > An IPFIX Message is a message originating at the Exporting Process > > that carries the IPFIX records of this Exporting Process and whose > > destination is a Collecting Process. An IPFIX Message is > > encapsulated at the transport layer. > > > > Information Element > > > > An Information Element is a protocol and encoding-independent > > description of an attribute that may appear in an IPFIX Record. > > The IPFIX information model [RFC5102] defines the base set of > > Information Elements for of several other Observation Points. For > > example, one Observation Point can be an entire line card. That > > would be the superset of the individual Observation Points at the > > line card's interfaces. > > > > Observation Domain > > > > An Observation Domain is the largest set of Observation Points for > > which Flow information can be aggregated by a Metering Process. > > For example, a router line card may be an Observation Domain if it > > is composed of several interfaces, each of which is an Observation > > Point. In the IPFIX Message it generates, the Observation Domain > > includes its Observation Domain ID, which is unique per Exporting > > Process. That way, the Collecting Process can identify the > > specific Observation Domain from the Exporter that sends the IPFIX > > Messages. Every Observation Point is associated with an > > Observation Domain. It is RECOMMENDED that Observation Domain IDs > > also be unique per IPFIX Device. > > > > Flow Key > > > > Each of the fields that: > > > > 1. belong to the packet header (e.g., destination IP address), > > > > 2. are a property of the packet itself (e.g., packet length), > > > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > > number), > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 4] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > and that are used to define a Flow are termed Flow Keys. > > > > Flow Record > > > > A Flow Record contains information about a specific Flow that was > > observed at an Observation Point. A Flow Record contains measured > > properties of the Flow (e.g., the total number of bytes for all > > the Flow's packets) and usually characteristic properties of the > > Flow (e.g., source IP address). > > > > Packet Reports > > > > Packet Reports comprise a configurable subset of a packet's input > > to the Selection Process, including the Packet Content, > > information relating to its treatment (for example, the output > > interface), and its associated selection state (for example, a > > hash of the Packet Content). > > > > Exporting Process > > > > The Exporting Process sends Flow Records to one or more Collecting > > Processes. The Flow Records are generated by one or more Metering > > Processes. > > > > Exporter > > > > A device that hosts one or more Exporting Processes is termed an > > Exporter. > > > > IPFIX Device > > > > An IPFIX Device hosts at least one Exporting Process. It may host > > further Exporting Processes and arbitrary numbers of Observation > > Points and Metering Processes. > > > > Collecting Process > > > > A Collecting Process receives Flow Records from one or more > > Exporting Processes. The Collecting Process might process or > > store received Flow Records, but such actions are out of scope for > > this document. > > > > Collector > > > > A device that hosts one or more Collecting Processes is termed a > > Collector. > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 5] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > IPFIX Message > > > > An IPFIX Message is a message originating at the Exporting Process > > that carries the IPFIX records of this Exporting Process and whose > > destination is a Collecting Process. An IPFIX Message is > > encapsulated at the transport layer. > > > > Information Element > > > > An Information Element is a protocol and encoding-independent > > description of an attribute that may appear in an IPFIX Record. > > The IPFIX information model [RFC5102] defines the base set of > > Information Elements foIPFIX. The type associated with an > > Information Element indicates constraints on what it may contain > > and also determines the valid encoding mechanisms for use in > > IPFIX. > > > > IPFIX Mediation > > > > IPFIX Mediation is a function located between Exporting Processes > > and Collecting Processes. The IPFIX Mediation can be included in > > Isn't it located between a Collecting Process and an Exporting Process? > > CP => Mediation => EP I should replace it with following description. Mediation is located in between components: Metering Processes, Exporting Processes, Collecting Processes, and other applications. If Mediation is hosted in Exporter, it is located between Metering Processes and Exporting Processes. > > > any IPFIX Devices. The IPFIX Mediation consists of a set of some > > of functions: > > "IPFIX Mediation consists of one or multiple of the following functions:" > > > > > * rerouting input Flow Records/Packet Reports to a appropriate > > Collecting Process > > BTW: this is a proxy function, so mediation is an umbrella term (see above) > > > * replicating input Flow Records/Packet Reports > > Not clear for what purpose Records should be replicated. Maybe add "in > order to ....". Yes. in order to distribute them to several Collectors > > > * filtering and selecting input Flow Records/Packet Reports > > remove "input"? > > > * aggregating input Flow Records/Packet Reports based on new Flow > > Keys > > "based on a new set of Flow Key fields"? > Yes. > > * correlating a set of Flow Records/Packet Reports for creating > > new Flow Records/Packet Reports with new metrics > > > > * modifying input Flow Records/Packet Reports > > remove "input"? > > > * changing a transport protocol which carries IPFIX Messages > > "changing the transport protocol" > > > The modification of Flow Records/Packet Reports includes these > > functions: > > > > * changing the value of specified Information Elements > > > > * adding new Information Elements by deriving further Flow or > > packet properties from existing fields or calculating new > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 6] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > metrics > > > > * deleting specified Information Elements. > > I would move these bullet points below "modifying Flow Records/Packet > Reports" in the preceding list because at that time the reader already > wonders what "modify" could mean. Yes. > > > > IPFIX Mediation can be included in any devices, such as routers, > > switches, NMS(Network Management Systems), or be deployed in > > stand-alone devices. > > I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX > Mediators. If performed on the original exporter, we already do have the > Metering Process which can do all these things. > I can image that IPFIX Mediation function is located between Metering and Exporting Process. > > > > Flow-Based Collector Selection > > > > The Flow-Based Collector Selection evaluates an input Flow Record/ > > Packet Report based on the value of the specified Information > > Element and then selects Collector for each input Flow Record/ > > Packet Report. > > "Flow-Based Collector Selection is an IPFIX Mediation function which > selects a Collector for every Flow Record/Packet Report. The selection > of a Collector is based on match filters applied to record fields > identified by Information Elements." Thank you. > > > IPFIX Mediator > > > > An IPFIX Mediator contains one or more functions defined in IPFIX > > "one or more IPFIX Mediation functions" > > > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > > device. It also contains one or more Collecting Processes and one > > What do you mean by "r IPFIX. The type associated with an > > Information Element indicates constraints on what it may contain > > and also determines the valid encoding mechanisms for use in > > IPFIX. > > > > IPFIX Mediation > > > > IPFIX Mediation is a function located between Exporting Processes > > and Collecting Processes. The IPFIX Mediation can be included in > > Isn't it located between a Collecting Process and an Exporting Process? > > CP => Mediation => EP I should replace it with following description. Mediation is located in between components: Metering Processes, Exporting Processes, Collecting Processes, and other applications. If Mediation is hosted in Exporter, it is located between Metering Processes and Exporting Processes. > > > any IPFIX Devices. The IPFIX Mediation consists of a set of some > > of functions: > > "IPFIX Mediation consists of one or multiple of the following functions:" > > > > > * rerouting input Flow Records/Packet Reports to a appropriate > > Collecting Process > > BTW: this is a proxy function, so mediation is an umbrella term (see above) > > > * replicating input Flow Records/Packet Reports > > Not clear for what purpose Records should be replicated. Maybe add "in > order to ....". Yes. in order to distribute them to several Collectors > > > * filtering and selecting input Flow Records/Packet Reports > > remove "input"? > > > * aggregating input Flow Records/Packet Reports based on new Flow > > Keys > > "based on a new set of Flow Key fields"? > Yes. > > * correlating a set of Flow Records/Packet Reports for creating > > new Flow Records/Packet Reports with new metrics > > > > * modifying input Flow Records/Packet Reports > > remove "input"? > > > * changing a transport protocol which carries IPFIX Messages > > "changing the transport protocol" > > > The modification of Flow Records/Packet Reports includes these > > functions: > > > > * changing the value of specified Information Elements > > > > * adding new Information Elements by deriving further Flow or > > packet properties from existing fields or calculating new > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 6] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > metrics > > > > * deleting specified Information Elements. > > I would move these bullet points below "modifying Flow Records/Packet > Reports" in the preceding list because at that time the reader already > wonders what "modify" could mean. Yes. > > > > IPFIX Mediation can be included in any devices, such as routers, > > switches, NMS(Network Management Systems), or be deployed in > > stand-alone devices. > > I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX > Mediators. If performed on the original exporter, we already do have the > Metering Process which can do all these things. > I can image that IPFIX Mediation function is located between Metering and Exporting Process. > > > > Flow-Based Collector Selection > > > > The Flow-Based Collector Selection evaluates an input Flow Record/ > > Packet Report based on the value of the specified Information > > Element and then selects Collector for each input Flow Record/ > > Packet Report. > > "Flow-Based Collector Selection is an IPFIX Mediation function which > selects a Collector for every Flow Record/Packet Report. The selection > of a Collector is based on match filters applied to record fields > identified by Information Elements." Thank you. > > > IPFIX Mediator > > > > An IPFIX Mediator contains one or more functions defined in IPFIX > > "one or more IPFIX Mediation functions" > > > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > > device. It also contains one or more Collecting Processes and one > > What do you mean byvirtual"? > If IPFIX Mediator and Exporter are located in same device, IPFIX Mediator is virtual device rather than stand-alone. I would not rather restrict possible implementations. > > or more Exporting Processes. > > > > Original Exporter > > > > An Original Exporter is an IPFIX Device which hosts Observation > > Points where IP packets can be directly observed. > > "where the metered IP packets are observed" > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > > from Original Exporter, and sends IPFIX Messages to one or more > > It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX > Mediator? Yes. I would not rather restrict it. I need to improve them. > > Sending to multiple Collectors requires "replication" of IPFIX Messages, > which implies that the included records are replicated as well. Yes. > You mention "replication" in the case of IPFIX Distributor below. Maybe > you want to mention it here as well? No. As you mentioned below, I mean IPFIX Distributor replicates Records. > > > Collectors. It may alter a part of IPFIX Message in order to > > "a part of the" > > > comply with IPFIX Protocol specifications. It may also change > > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > > "change the transport protocol" > > > and convert a legacy protocol message to an IPFIX Message, if > > necessary. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > > Records/Packet Reports, aggregates them, then exports the > > aggregated Flow Records. > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > > Records/Packet Reports based on the result of Flow-Based Collector > > Selection. It may filter or replicate input Flow Records/Packet > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 7] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > Reports, if necessary. > > What is the difference between IPFIX Proxy and IPFIX Distributor? > Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX > Distributor handles individual records? > Yes. > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > > a part of data of input Flow Records/Packet Reports according to > > configured policies. It can thus, for example, hide the network > > topology information or customers' IP addresses. > > Note: If you call this a "proxy", then my above distinction between > IPFIX Proxy and IPFIX Distributor does not work. Is it strange that IPFIX Masquerading Proxy handles Records, although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handles Records? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 8] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 3. Flow-Based Mediation: Applicability Examples > > > > > > 3.1. IPFIX Export Across Domains > > > > > > IPFIX export across administrative domains can be used to measure > > traffic for wide-area traffic engineering, or to analyze the trend of > > Internet traffic. In such cases, operators need to adhere to privacy > > policies and prevent the transmission of confidential information. > > "prevent the transmission of confidential information" is unclear. > Rather: "prevent the access to confidential traffic measurements by > other operators" Thanks. > > > Using an IPFIX Masquerading Proxy allows them to operate on Flow > > Records safely by anonymizing and filtering them. IP Flow > > Who operate "virtual"? > If IPFIX Mediator and Exporter are located in same device, IPFIX Mediator is virtual device rather than stand-alone. I would not rather restrict possible implementations. > > or more Exporting Processes. > > > > Original Exporter > > > > An Original Exporter is an IPFIX Device which hosts Observation > > Points where IP packets can be directly observed. > > "where the metered IP packets are observed" > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > > from Original Exporter, and sends IPFIX Messages to one or more > > It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX > Mediator? Yes. I would not rather restrict it. I need to improve them. > > Sending to multiple Collectors requires "replication" of IPFIX Messages, > which implies that the included records are replicated as well. Yes. > You mention "replication" in the case of IPFIX Distributor below. Maybe > you want to mention it here as well? No. As you mentioned below, I mean IPFIX Distributor replicates Records. > > > Collectors. It may alter a part of IPFIX Message in order to > > "a part of the" > > > comply with IPFIX Protocol specifications. It may also change > > type of transport protocol, such as UDP, TCP, SCTP and PR-SCTP, > > "change the transport protocol" > > > and convert a legacy protocol message to an IPFIX Message, if > > necessary. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > > Records/Packet Reports, aggregates them, then exports the > > aggregated Flow Records. > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > > Records/Packet Reports based on the result of Flow-Based Collector > > Selection. It may filter or replicate input Flow Records/Packet > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 7] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > Reports, if necessary. > > What is the difference between IPFIX Proxy and IPFIX Distributor? > Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX > Distributor handles individual records? > Yes. > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > > a part of data of input Flow Records/Packet Reports according to > > configured policies. It can thus, for example, hide the network > > topology information or customers' IP addresses. > > Note: If you call this a "proxy", then my above distinction between > IPFIX Proxy and IPFIX Distributor does not work. Is it strange that IPFIX Masquerading Proxy handles Records, although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handles Records? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 8] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 3. Flow-Based Mediation: Applicability Examples > > > > > > 3.1. IPFIX Export Across Domains > > > > > > IPFIX export across administrative domains can be used to measure > > traffic for wide-area traffic engineering, or to analyze the trend of > > Internet traffic. In such cases, operators need to adhere to privacy > > policies and prevent the transmission of confidential information. > > "prevent the transmission of confidential information" is unclear. > Rather: "prevent the access to confidential traffic measurements by > other operators" Thanks. > > > Using an IPFIX Masquerading Proxy allows them to operate on Flow > > Records safely by anonymizing and filtering them. IP Flow > > Who operas on the Flow Records? > Anonymization rather makes it possible to give the Flow Records away to > other operators without violating privacy policies. > Yes. I will add your points regarding other operators view. > > anonymisation is described in [I-D.boschi-ipfix-anon] in detail. > > > > 3.2. Data Retention > > > > > > Data retention refers to the storage of traffic data by service > > providers and commercial organizations. According to European > > Commission directives, operators are required to retain both IP and > > voice traffic data, in wired and wireless networks, generated by end > > users while using a service provider's services. The goal of data > > retention is to ensure that call detail records and Flow Records are > > available for the purpose of detection, investigation, and > > prosecution of serious crimes, if necessary. The European Commission > > directives define the following data retention services: > > > > o Fixed telephony (includes fixed voice, voicemail, and conference > > and data calls) > > > > o Mobile telephony (includes mobile voice, voicemail, conference and > > data calls, SMS, and MMS) > > > > o Internet telephony (includes every multimedia session associated > > with IP multimedia services) > > > > o Internet e-mail > > > > o Internet access > > > > By monitoring Flow Records, IPFIX can fulfill these requirements of > > Internet access services. > > Ok, but where is the link to IPFIX Mediation? > It is possible examples. IPFIX Mediation with storage allow collection system to become huge storage to suit data retention. > > 3.3. Interoperability between Legacy Protocols and IPFIX > > > > > > During the migration process from a legacy protocol such as NetFlow > > [RFC3954] to IPFIX, both NetFlow and IPFIX Exporters will need to co- > > "are likely to coexist" > > > exist in the same network. An IPFIX Proxy which converts a legacy > > protocol to IPFIX will allow operators to continue measuring Flows > > from legacy Exporters, even after introducing IPFIX Collectors. > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 9] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 3.4. Rerouting Flow Records/Packet Reports > > > > > > Recently, several networks seem to have shifted towards integrated > > remove "seem to" > > > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > > and VPN traffic. Flow Records/Packet Reports of these types need to > > "...of different networks need to..." > > > be analyzed separately and from different perspectives. However, > > handling them separately without improving the capability of the > > Collector is difficult. An IPFIX Distributor rerouting Flow Records/ > > Packet Reports based on the result of Flow-based Collector Selection, > > would be necessary. Thus, it allows individual Collectors related to > > "An IPFIX Distributor allows separating and rerouting Flow > Records/Packet Reports from different networks to different Collectors > based on Flow-based Collector Selection." > > > each network to analyze traffic data for their own specific purposes. > > > > As another example, in case of rerouting specific customer's Flow > > Records, an IPFIX Distributor needs to identify each customer. As > > it rather needs to identify the customer networks > Yes. > > identification data, the RD (Route Distinguisher), ingress IF, > > What is "IF"? > > > peering AS number, or BGP next hop are listed. As shown in the > > Where are they listed? > > Proposed formulation: > "RD (..), ingress interface, ....., may be evaluated to distinguish > different customer networks." Exactly. > > > following figure, the IPFIX Distributor reroutes Flow Records based > > remove "As shown" > > > on the RD value. This system allows each customer's traffic to be > > inspected independently. > > > > tes on the Flow Records? > Anonymization rather makes it possible to give the Flow Records away to > other operators without violating privacy policies. > Yes. I will add your points regarding other operators view. > > anonymisation is described in [I-D.boschi-ipfix-anon] in detail. > > > > 3.2. Data Retention > > > > > > Data retention refers to the storage of traffic data by service > > providers and commercial organizations. According to European > > Commission directives, operators are required to retain both IP and > > voice traffic data, in wired and wireless networks, generated by end > > users while using a service provider's services. The goal of data > > retention is to ensure that call detail records and Flow Records are > > available for the purpose of detection, investigation, and > > prosecution of serious crimes, if necessary. The European Commission > > directives define the following data retention services: > > > > o Fixed telephony (includes fixed voice, voicemail, and conference > > and data calls) > > > > o Mobile telephony (includes mobile voice, voicemail, conference and > > data calls, SMS, and MMS) > > > > o Internet telephony (includes every multimedia session associated > > with IP multimedia services) > > > > o Internet e-mail > > > > o Internet access > > > > By monitoring Flow Records, IPFIX can fulfill these requirements of > > Internet access services. > > Ok, but where is the link to IPFIX Mediation? > It is possible examples. IPFIX Mediation with storage allow collection system to become huge storage to suit data retention. > > 3.3. Interoperability between Legacy Protocols and IPFIX > > > > > > During the migration process from a legacy protocol such as NetFlow > > [RFC3954] to IPFIX, both NetFlow and IPFIX Exporters will need to co- > > "are likely to coexist" > > > exist in the same network. An IPFIX Proxy which converts a legacy > > protocol to IPFIX will allow operators to continue measuring Flows > > from legacy Exporters, even after introducing IPFIX Collectors. > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 9] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 3.4. Rerouting Flow Records/Packet Reports > > > > > > Recently, several networks seem to have shifted towards integrated > > remove "seem to" > > > networks, such as the Internet and MPLS, which includes IPv4, IPv6, > > and VPN traffic. Flow Records/Packet Reports of these types need to > > "...of different networks need to..." > > > be analyzed separately and from different perspectives. However, > > handling them separately without improving the capability of the > > Collector is difficult. An IPFIX Distributor rerouting Flow Records/ > > Packet Reports based on the result of Flow-based Collector Selection, > > would be necessary. Thus, it allows individual Collectors related to > > "An IPFIX Distributor allows separating and rerouting Flow > Records/Packet Reports from different networks to different Collectors > based on Flow-based Collector Selection." > > > each network to analyze traffic data for their own specific purposes. > > > > As another example, in case of rerouting specific customer's Flow > > Records, an IPFIX Distributor needs to identify each customer. As > > it rather needs to identify the customer networks > Yes. > > identification data, the RD (Route Distinguisher), ingress IF, > > What is "IF"? > > > peering AS number, or BGP next hop are listed. As shown in the > > Where are they listed? > > Proposed formulation: > "RD (..), ingress interface, ....., may be evaluated to distinguish > different customer networks." Exactly. > > > following figure, the IPFIX Distributor reroutes Flow Records based > > remove "As shown" > > > on the RD value. This system allows each customer's traffic to be > > inspected independently. > > > > .---------. > > |Traffic | > > .---->|Collector|<==>Customer#A > > | |#1 | > > | '---------' > > RD=100:1 > > .-----------. | > > .--------. |IPFIX |----' .---------. > > |IPFIX | |Distributor| RD=100:2 |Traffic | > > |router#1|------->| |--------->|Collector|<==>Customer#B > > | | | | |#2 | > > '--------' | |----. '---------' > > '-----------' | > > RD=100:3 > > | .---------. > > | |Traffic | > > '---->|Collector|<==>Customer#C > > |#3 | > > '---------' > > > > Figure A: Rerouting Flow Records to Collectors using IPFIX > > Distributor > > > > 3.5. IPFIX Export from Branch Office > > > > > > Generally, in big enterprise networks, traffic data from branch > > offices is gathered in a central office. But, in the long distance > > branch office case, the bandwidth for transport IPFIX is not enough. > > "sufficient" > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 10] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > Therefore, it is beneficial that an IPFIX Concentrator located in a > > branch office exports aggregated Flow Records to cope with the > > limitation of bandwidth. > > > > 3.6. Correlation of Flow Records/Packet Reports Information > > > > > > The correlation of Flow Records/Packet Reports information offers > > some new metrics. There are some examples as follows: > > > > o One way delay follows from correlating Packet Reports exported > > from different Exporters on the path. > > > > o The result of a queueing or rate-limiting function applied to > > "queuing" > > > ingress or egress interface follows from correlating Flow Records > > with the same Flow Key observed at both interfaces. > > > > o Average/maximum/minimum values follow from correlating each in a > > set of Flow Records. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 11] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 4. Approaches to Scalability > > > > > > Usually, operators measure traffic at several Observation Points for > > a specific purpose, typically sampling packets with rates ranging > > from 1/10,000 to 1/100. This value depends on several factors, such > > as the capacity of the management network, the available storage and > > speed of the Collector, and the load on the routers/switches. > > > > On the one hand, the number of Observation Points in the networks can > > even be increased to improve the effectiveness of these methods. In > > "is expected to increase in order to" > > > the near future, we anticipate that the advanced features of IPFIX, > > such as the monitoring of wide-area traffic matrices and QoS > > performance, will accelerate IPFIX utilization. > > > > On the other hand, the increasing amount of traffic brought about by > > broadband users might have an impact on measurement parameters, such > > as the sampling rate or granularity of Flows. Generally, large-scale > > networks already have multiple 10 Gb/s links, their total traffic > > exceeding 100 Gb/s. .---------. > > |Traffic | > > .---->|Collector|<==>Customer#A > > | |#1 | > > | '---------' > > RD=100:1 > > .-----------. | > > .--------. |IPFIX |----' .---------. > > |IPFIX | |Distributor| RD=100:2 |Traffic | > > |router#1|------->| |--------->|Collector|<==>Customer#B > > | | | | |#2 | > > '--------' | |----. '---------' > > '-----------' | > > RD=100:3 > > | .---------. > > | |Traffic | > > '---->|Collector|<==>Customer#C > > |#3 | > > '---------' > > > > Figure A: Rerouting Flow Records to Collectors using IPFIX > > Distributor > > > > 3.5. IPFIX Export from Branch Office > > > > > > Generally, in big enterprise networks, traffic data from branch > > offices is gathered in a central office. But, in the long distance > > branch office case, the bandwidth for transport IPFIX is not enough. > > "sufficient" > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 10] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > Therefore, it is beneficial that an IPFIX Concentrator located in a > > branch office exports aggregated Flow Records to cope with the > > limitation of bandwidth. > > > > 3.6. Correlation of Flow Records/Packet Reports Information > > > > > > The correlation of Flow Records/Packet Reports information offers > > some new metrics. There are some examples as follows: > > > > o One way delay follows from correlating Packet Reports exported > > from different Exporters on the path. > > > > o The result of a queueing or rate-limiting function applied to > > "queuing" > > > ingress or egress interface follows from correlating Flow Records > > with the same Flow Key observed at both interfaces. > > > > o Average/maximum/minimum values follow from correlating each in a > > set of Flow Records. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 11] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 4. Approaches to Scalability > > > > > > Usually, operators measure traffic at several Observation Points for > > a specific purpose, typically sampling packets with rates ranging > > from 1/10,000 to 1/100. This value depends on several factors, such > > as the capacity of the management network, the available storage and > > speed of the Collector, and the load on the routers/switches. > > > > On the one hand, the number of Observation Points in the networks can > > even be increased to improve the effectiveness of these methods. In > > "is expected to increase in order to" > > > the near future, we anticipate that the advanced features of IPFIX, > > such as the monitoring of wide-area traffic matrices and QoS > > performance, will accelerate IPFIX utilization. > > > > On the other hand, the increasing amount of traffic brought about by > > broadband users might have an impact on measurement parameters, such > > as the sampling rate or granularity of Flows. Generally, large-scale > > networks already have multiple 10 Gb/s links, their total traffic > > exceeding 100 Gb/ In the near future, broadband users' traffic > > will increase by approximately 50% per year according to [TRAFGRW]. > > When operators monitor traffic of 500 Gb/s with a sampling rate of > > 1/1000, the amount of exported Flow Records from Exporters could > > exceed 50 kFlows/s. This value is beyond the ability of a single > > Collector. > > > > This section explains how operators can cope with such a huge amount > > of Flow Records using available IPFIX solutions. Generally, the > > solutions encompass two approaches: reducing the amount of exported > > Flow Records or increasing the capacity of the Collecting Process. > > The following sub-sections show each solution. > > > > 4.1. Adjusting Sampling Rates > > > > > > Adjusting the sampling rate can reduce the amount of Flow Records, > > and a flow-based measurement system can thus easily adapt to the > > ability of the Collecting and Exporting Processes. However, in that > > case, Flows with small traffic volumes could easily get lost. If > > traffic incidents happened, operators would no longer be able to > > investigate traffic change. While traffic volumes on networks > > "If traffic volumes ..." > > > continue to increase, operators will not be able to maintain the > > sampling rates currently used. In the near future, flow-based > > measurement systems possibly will not be able to detect traffic > > anomalies which can currently be detected. > > > > 4.2. Flow Aggregation > > > > > > The simplest types of Flows are those comprised of all packets having > > a fixed five tuple of protocol, source and destination IP addresses, > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 12] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > and source and destination port numbers. On the other hand, choosing > > a shorter Flow Key, such as a three tuple or two tuple, or a single > > Flow Key, such as a network prefix, peering AS number, or BGP Next- > > Hop, creates more aggregated Flow Records. This solution is > > especially useful for measurements of traffic exchange in an entire > > network domain and for easy adjustments to the performance of a > > Collector. > > > > 4.2.1. Flow Aggregation on Original Exporters > > > > > > Original Exporters can aggregate Flow Records to reduce the amount of > > them. But, in-depth traffic monitoring might not be possible, as it > > is with the five tuple. One way to this is to be able to specify the > > Template Records for specific needs. This extra flexibility in the > > If you want to adopt the terminology from IPFIX configuration, it's the > Cache Layout that is configured (not the Template Record). In the vision > of IPFIX configuration, the Template Record results from the Cache > Layout, not the other way round. > Using Cache Layout seems to make the description more simple. > > Metering Process allows operators to specify their own set of Flow > > Keys and extra Information Elements in the Template Record. > > Specifically, Original Exporters classify the Flow Records by their > > contents, and then aggregate them with appropriate Flow keys based on > > You assume one specific implementation where the Metering Process first > produces IP-quintuple Flows which are then aggregated. However, it is > also possible to directly generate Flows with Flow Key fields differing > from the usual IP-quintuple. In this case, it is not an IPFIX Mediation > function but just a Metering Process. Also, I would not call this case > flow "aggregation". > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And then, Metering Process can create aggregated Flow Records without Mediation. But, in some case, Metering Process in port module creates IP-quintuple Flow and then mediation function in main cpu creates aggregated Flow. > > a specific application. There is an application for security, > > The Exporter is not aware of any "application", it only functions > according to its configuration. So, I would remove "based on a specific > application". You might replace it by "based on a given configuration". Exactly. > > > another for capacity planning, and so on. The content and > > granularity of the Flow can satisfy the requirements of each > > Collector with a specific application. > > > > On one hand, this optimizes the Metering Process, because only Flows > > of interest are looked at. On the other hand, it optimizes the > > Exporting Process, because only the information of interest is > > exported. Finally, this reduces load of the Collecting Process as > > less Flow Records are handled, and Flow Record filtering and > > aggregating are required. > > Ok. So this subsection proposed a solution that works without IPFIX > Mediation. > Yes... I write down several solution against the large traffic volume in the sections regardless of whether using Mediation or not. Does it confuse you? > > 4.2.2. Flow Aggregation on IPFIX Concentrators > > > > > > Another approach involves a hierarchical measurement system using > > IPFIX Concentrators. Aggregation and storage for input Flow Records > > RFC 3917: > A concentrator receives flow records via the IPFIX protocol, merges > them into more aggregated flow records, and exports them again using > the IPFIX protocol. > > So, storing records is not a primary function of an IPFIX Concentrator > as you write here. > Exactly, I will add the note. > > on IPFIX Concentrators makes a most useful distributed-collection > > system. It allows other devices to retrieve the stored Flow Record. > > This method increases the capacity of Collecting Process of whole > > system. Flow aggregation method is described in > > [I-D.dressler-ipfix-aggregation] in detail. > > > > 4.3. Time Composition > > > > > > Time composition is defined as aggregation for consecutive Flow > > Records with same Flow Keys. It leads to the same output as setting > > rather: "with identical Flow Key values" > > > a longer active interval timer on Original Exporters. However, an > > IPFIX Mediation can calculate average, maximum and minimum values of > > each counter from Flow Records received with shorter interval time. > > The output allows operators to keep track of changes that might have > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 13] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > happened during the time interval. > > > > 4.4. Space Composition > > > > > > Space composition is defined as aggregation for one or more Flow > > Records involved in a larger Observation Domain or a set of > > Observation Points. It is divided into two types: > > > > o Space Composition within one Exporter > > > > In that case, the spatial range is within one Exporters. For > > "Exporter" > > > example, the Flow Records observed at physical interfaces which > > belong to virtual interface by link aggregation can be composed to > > one Flow Records. > > I do not understand. > The Flow Records observed at physical interfaces which belong to a link aggregation group can be composed to one Flow Records. > > o Space Composition within some Exporters > > > > In that case, the spatial range consists of some different > > Exporters. For example, the Flow Records observed at same domain, > > "in the same domain" > > > such as west area and east area of an ISP network, can be composed > > to one Flow Records. > > > > 4.5. Distributing Load among Collectors > > > > > > As described in the previous section, an IPFIX Distributor reroutes > > Flow Records/Packet Reports to appropriate Collectors based on the > > result of the Flow-based Collector Selection. It can thus distribute > > the load among multiple Collectors according to a specific > > application, each area, or each customer. > > > > 4.6. Flow Selection Sampling > > > > > > A Flow selection sampling method is described in > > [I-D.peluso-flowselection] in detail. Generally, the distribution of > > the number of packets per Flow seems to be heavy-tailed. Most types > > of Flow Records are likely to be small Flows consisting of a small > > number of packets. The flow-based measurement system, in particular > > the Collecting Process and Exporting Process, is burdened with a huge > > amount of these small Flows. If statistics information of small > > Flows is exported as merging data by applying a policy or threshold, > > "merged data"? > > > the burden on measurement system is reduced. > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 14] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 5. Problems with using IPFIX Mediators > > > > > > In this section, we focus on the problems related to the use of IPFIX > > Mediators in consideration of implementation. > > > > 5.1. Loss of Observation Point Information > > > > > > Both the Exporter IP address indicated by the source IP address of > > the IPFIX session as well as the Observation Domain ID included in > > the IPFIX header are likely to be lost in the mediation process > > "IPFIX Message header" > > > performed by an IPFIX Mediator. This IP address and Observation > > Domain ID indicate the Observation Point information from the > > viewpoint of the entire network domain. Such information is > > necessary for guaranteeing the continuity of the work of the top > > level Collector. Even if an IPFIX Mediator could, with some new > > mechanism, notify Collectors of this Observation Point information, > > older Collectors might not accept it. These Collectors would then > > wrongly assume that the IP address of the IPFIX Mediator is that of > > the Original Exporter. The Collector, however, needs to recognize > > the precise Observation Point whether Flow Records go through an > > IPFIX Mediator or not. > > > > In the following figure, a Collector could identify 2 Exporters with > > IP addresses of 10.1.1.3 and 10.1.1.2, respectively. The Collector, > > however, needs to somehow recognize Router#1 and Router#2, which are > > the Original Exporters. Defined notification methods that can be > > interpreted by Collectors and Mediators are thus necessary. > > > > .--------. .--------. > > |IPFIX | |IPFIX | > > |Router#1|--------->|Mediator|---+ > > | | | | | > > '--------' '--------' | .---------. > > IP:10.1.1.1 IP:10.1.1.3 '----->| | > > ODID:10 ODID:0 |Collector| > > +----->| | > > .--------. | '---------' > > |IPFIX | | > > |Router#2|-----------------------' > > | | > > '--------' > > IP:10.1.1.2 > > ODID:20 > > > > Figure B: Loss of Observation Point Information. > > In some cases, e.g. masquerading, it might be desired to drop OD > information ;) > Yes. It depends on the configuration policy. > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 15] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 5.2. Loss of Base Time Information > > > > > > The Export Time field included in the IPFIX header indicates the base > > time for Flow Records. In IPFIX Information Elements, described in > > [RFC5102], there are delta time fields that indicate the time > > difference from the value of the Export Time field. If the Flow > > Records include any delta time fields and the IPFIX Mediator > > overwrites the Export Time field when sending IPFIX messages, the > > delta time fields become meaningless and, because Collectors can not > > recognize this situation, wrong time values are propagated. > > In the described case, the delta time fields contain wrong values > regardless of whether the Collector recognizes this situation or not! > I will remove "because Collectors can not recognize this situation". > > > > 5.3. Loss of Option Template Information > > > > > > In some cases, depending on the implementation of the IPFIX > > Mediators, the information that is reported by the Option Templates > > could also be lost. If, for example, the sampling rate is not > > communicated to the Collectors, a Collector would miscalculate the > > traffic volume. This might bring crucial problems. Even if an IPFIX > > Mediator were to simply relay received Option Template Information, > > "was to" > > > the value of its scope fields would become meaningless in the context > > "could become" > > > of a different session. It should be noted that the minimal > > information to be communicated by an IPFIX Mediator needs to be > > defined. > > remove "it should be noted that" > > > > > 5.4. Observation Domain ID and Template ID Management > > > > > > The Observation Domain ID is locally unique to the Exporting Process > > in an IPFIX Mediator, just like the Template ID is unique on the > > basis of the Observation Domain ID. These renewed identifiers should > > Be careful with repeating incomplete RFC5101 specs. Template IDs are > unique per Transport Session! I will improve it. > > > be managed using the Transport Session Information of the Collecting > > Process. If IPFIX Mediators could not manage the relations among > > "were not able to" > > > these identifiers and the received Transport Session Information, the > > Mediators would, for example, relay wrong values for the scope fields > > of the Option Template and for a "Template Withdraw Message". In > > You assume that the Template ID is in the Option's scope. That does not > have to be the case. > Generally, Template ID is used as the Option's scope. > > most cases, a Collector would not be able to interpret the Template > > ID of a "Template Withdraw Message" and the scope fields of an Option > > Template. The Collector would then shut down the IPFIX Session. > > > > 5.5. Transport Sessions Management > > > > > > How an IPFIX Mediator maintains relationships between the Transport > > Sessions of Collecting Processes and of Exporting Processes depends > > on its implementation. If multiple Transport Sessions of the > > Collecting Process are relayed to single Transport Session of the > > Exporting Process and the IPFIX Mediators shuts down the Transport > > Session of the Exporting Process, Flow Records on other Transport > > Sessions of the Collecting Processes would not be relayed at all. In > > the case of resetting a session of the Collecting Process, the > > I do not see a problem here. Outgoing transport session and incoming > transport sessions should be independent and configurable. There is no > automatism to shut down an outgoing session because an incoming session > closes. > It shows the possible problems. If outgoing transport session and incoming transport sessions should be independent and configurable, a problem do not happen. Certainly, Yes. I intended that outgoing transport session and incoming transport sessions should be independent in any case. Um, this subsection seems to be removed. > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 16] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > behavior of the IPFIX Mediator needs to be defined. > > > > > > .--------. > > |IPFIX | > > |Router#1|----+ > > | | | > > '--------' X > > .--------. | .--------. .---------. > > |IPFIX | '---->|IPFIX | | | > > |Router#2|--------->|Mediator|----X---->|Collector| > > | | +---->| | | | > > '--------' | '--------' '---------' > > .--------. | > > |IPFIX | | > > |Router#3|----' > > | | > > '--------' > > > > Figure C: Relaying from Multiple Transport Sessions to Single > > Transport Session. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 17] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 6. Conclusion > > > > > > This document has covered the applicability of IPFIX Mediation and a > > multitude of problems related to the implementation of IPFIX > > Mediators. To assist the ability of the Exporters and Collectors, it > > should be noted that there are various IPFIX Mediation functions for > > the operators to select from. Examples of the applicability of IPFIX > > Mediation are as follows. > > > > o Regarding IPFIX Exporting across domains, IPFIX Masquerading > > Proxies help operators to anonymize or filter Flow Records/Packet > > Reports, preventing privacy violations. > > > > o Regarding data retention, IPFIX Mediators enhance the storage of > > the measurement system. > > > > o Regarding interoperability, IPFIX Proxies provide interoperability > > between legacy protocols and IPFIX, even during the migration > > period to IPFIX. > > > > o Regarding the Flow-based Collector Selection function, in > > integrated networks, which mix MPLS VPN and IPv4/IPv6, this could > > be utilized more frequently. More sophisticated implementation > > methods would enhance the effectiveness. > > > > o Regarding scalability in large-scale networks, IPFIX Concentrators > > or IPFIX Distributors help to achieve high sample rates and fine- > > grained Flow analysis even as networks grow. As IPFIX Mediation > > functions, Flow selection sampling, aggregation and composition > > are beneficial. > > > > As a result, the benefits of IPFIX Mediation become apparent. > > However, there are still some open issues. > > > > o With the use of IPFIX Mediators, both Observation Point and IPFIX > > header information, such as the Exporter IP address, Observation > > Domain ID, and Export Time field, might be lost. This data should > > therefore be communicated between the Original Exporter and > > Collector via the IPFIX Mediator. > > > > o With the use of IPFIX Mediators, data advertised by Option > > Templates from the Original Exporter, such as the sampling rate > > and sampling algorithm used, might be lost. If a Collector is not > > informed of current sampling rates, traffic information might > > become worthless. > > > > o IPFIX Mediators are required to manage Transport Sessions, > > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 18] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > IPFIX messages could be created. > > > > These problems stem from the fact that no standards regarding IPFIX > > Mediation have been set. In particular, the minimum set of > > information which should be communicated between Original Exporters > > and Collectors, interworking between different IPFIX Transport > > Sessions, and the internal components of IPFIX Mediators should be > > standardized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 19] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 7. Security Considerations > > > > > > A flow-based measurement system might lead to privacy violations, > > such as the export of Flow Records to an outside address, if the > > system is not confined to the large-scale network under observation. > > General security issues of the IPFIX protocol are covered by the > > security considerations section in [RFC5101]. Security MUST be > > considered if different networks exchange Flow information. As the > > security of the exchange relies mostly on the protocol used, UDP does > > not seem appropriate for the exchange of information between > > networks. > > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix s. In the near future, broadband users' traffic > > will increase by approximately 50% per year according to [TRAFGRW]. > > When operators monitor traffic of 500 Gb/s with a sampling rate of > > 1/1000, the amount of exported Flow Records from Exporters could > > exceed 50 kFlows/s. This value is beyond the ability of a single > > Collector. > > > > This section explains how operators can cope with such a huge amount > > of Flow Records using available IPFIX solutions. Generally, the > > solutions encompass two approaches: reducing the amount of exported > > Flow Records or increasing the capacity of the Collecting Process. > > The following sub-sections show each solution. > > > > 4.1. Adjusting Sampling Rates > > > > > > Adjusting the sampling rate can reduce the amount of Flow Records, > > and a flow-based measurement system can thus easily adapt to the > > ability of the Collecting and Exporting Processes. However, in that > > case, Flows with small traffic volumes could easily get lost. If > > traffic incidents happened, operators would no longer be able to > > investigate traffic change. While traffic volumes on networks > > "If traffic volumes ..." > > > continue to increase, operators will not be able to maintain the > > sampling rates currently used. In the near future, flow-based > > measurement systems possibly will not be able to detect traffic > > anomalies which can currently be detected. > > > > 4.2. Flow Aggregation > > > > > > The simplest types of Flows are those comprised of all packets having > > a fixed five tuple of protocol, source and destination IP addresses, > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 12] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > and source and destination port numbers. On the other hand, choosing > > a shorter Flow Key, such as a three tuple or two tuple, or a single > > Flow Key, such as a network prefix, peering AS number, or BGP Next- > > Hop, creates more aggregated Flow Records. This solution is > > especially useful for measurements of traffic exchange in an entire > > network domain and for easy adjustments to the performance of a > > Collector. > > > > 4.2.1. Flow Aggregation on Original Exporters > > > > > > Original Exporters can aggregate Flow Records to reduce the amount of > > them. But, in-depth traffic monitoring might not be possible, as it > > is with the five tuple. One way to this is to be able to specify the > > Template Records for specific needs. This extra flexibility in the > > If you want to adopt the terminology from IPFIX configuration, it's the > Cache Layout that is configured (not the Template Record). In the vision > of IPFIX configuration, the Template Record results from the Cache > Layout, not the other way round. > Using Cache Layout seems to make the description more simple. > > Metering Process allows operators to specify their own set of Flow > > Keys and extra Information Elements in the Template Record. > > Specifically, Original Exporters classify the Flow Records by their > > contents, and then aggregate them with appropriate Flow keys based on > > You assume one specific implementation where the Metering Process first > produces IP-quintuple Flows which are then aggregated. However, it is > also possible to directly generate Flows with Flow Key fields differing > from the usual IP-quintuple. In this case, it is not an IPFIX Mediation > function but just a Metering Process. Also, I would not call this case > flow "aggregation". > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And then, Metering Process can create aggregated Flow Records without Mediation. But, in some case, Metering Process in port module creates IP-quintuple Flow and then mediation function in main cpu creates aggregated Flow. > > a specific application. There is an application for security, > > The Exporter is not aware of any "application", it only functions > according to its configuration. So, I would remove "based on a specific > application". You might replace it by "based on a given configuration". Exactly. > > > another for capacity planning, and so on. The content and > > granularity of the Flow can satisfy the requirements of each > > Collector with a specific application. > > > > On one hand, this optimizes the Metering Process, because only Flows > > of interest are looked at. On the other hand, it optimizes the > > Exporting Process, because only the information of interest is > > exported. Finally, this reduces load of the Collecting Process as > > less Flow Records are handled, and Flow Record filtering and > > aggregating are required. > > Ok. So this subsection proposed a solution that works without IPFIX > Mediation. > Yes... I write down several solution against the large traffic volume in the sections regardless of whether using Mediation or not. Does it confuse you? > > 4.2.2. Flow Aggregation on IPFIX Concentrators > > > > > > Another approach involves a hierarchical measurement system using > > IPFIX Concentrators. Aggregation and storage for input Flow Records > > RFC 3917: > A concentrator receives flow records via the IPFIX protocol, merges > them into more aggregated flow records, and exports them again using > the IPFIX protocol. > > So, storing records is not a primary function of an IPFIX Concentrator > as you write here. > Exactly, I will add the note. > > on IPFIX Concentrators makes a most useful distributed-collection > > system. It allows other devices to retrieve the stored Flow Record. > > This method increases the capacity of Collecting Process of whole > > system. Flow aggregation method is described in > > [I-D.dressler-ipfix-aggregation] in detail. > > > > 4.3. Time Composition > > > > > > Time composition is defined as aggregation for consecutive Flow > > Records with same Flow Keys. It leads to the same output as setting > > rather: "with identical Flow Key values" > > > a longer active interval timer on Original Exporters. However, an > > IPFIX Mediation can calculate average, maximum and minimum values of > > each counter from Flow Records received with shorter interval time. > > The output allows operators to keep track of changes that might have > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 13] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > happened during the time interval. > > > > 4.4. Space Composition > > > > > > Space composition is defined as aggregation for one or more Flow > > Records involved in a larger Observation Domain or a set of > > Observation Points. It is divided into two types: > > > > o Space Composition within one Exporter > > > > In that case, the spatial range is within one Exporters. For > > "Exporter" > > > example, the Flow Records observed at physical interfaces which > > belong to virtual interface by link aggregation can be composed to > > one Flow Records. > > I do not understand. > The Flow Records observed at physical interfaces which belong to a link aggregation group can be composed to one Flow Records. > > o Space Composition within some Exporters > > > > In that case, the spatial range consists of some different > > Exporters. For example, the Flow Records observed at same domain, > > "in the same domain" > > > such as west area and east area of an ISP network, can be composed > > to one Flow Records. > > > > 4.5. Distributing Load among Collectors > > > > > > As described in the previous section, an IPFIX Distributor reroutes > > Flow Records/Packet Reports to appropriate Collectors based on the > > result of the Flow-based Collector Selection. It can thus distribute > > the load among multiple Collectors according to a specific > > application, each area, or each customer. > > > > 4.6. Flow Selection Sampling > > > > > > A Flow selection sampling method is described in > > [I-D.peluso-flowselection] in detail. Generally, the distribution of > > the number of packets per Flow seems to be heavy-tailed. Most types > > of Flow Records are likely to be small Flows consisting of a small > > number of packets. The flow-based measurement system, in particular > > the Collecting Process and Exporting Process, is burdened with a huge > > amount of these small Flows. If statistics information of small > > Flows is exported as merging data by applying a policy or threshold, > > "merged data"? > > > the burden on measurement system is reduced. > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 14] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 5. Problems with using IPFIX Mediators > > > > > > In this section, we focus on the problems related to the use of IPFIX > > Mediators in consideration of implementation. > > > > 5.1. Loss of Observation Point Information > > > > > > Both the Exporter IP address indicated by the source IP address of > > the IPFIX session as well as the Observation Domain ID included in > > the IPFIX header are likely to be lost in the mediation process > > "IPFIX Message header" > > > performed by an IPFIX Mediator. This IP address and Observation > > Domain ID indicate the Observation Point information from the > > viewpoint of the entire network domain. Such information is > > necessary for guaranteeing the continuity of the work of the top > > level Collector. Even if an IPFIX Mediator could, with some new > > mechanism, notify Collectors of this Observation Point information, > > older Collectors might not accept it. These Collectors would then > > wrongly assume that the IP address of the IPFIX Mediator is that of > > the Original Exporter. The Collector, however, needs to recognize > > the precise Observation Point whether Flow Records go through an > > IPFIX Mediator or not. > > > > In the following figure, a Collector could identify 2 Exporters with > > IP addresses of 10.1.1.3 and 10.1.1.2, respectively. The Collector, > > however, needs to somehow recognize Router#1 and Router#2, which are > > the Original Exporters. Defined notification methods that can be > > interpreted by Collectors and Mediators are thus necessary. > > > > .--------. .--------. > > |IPFIX | |IPFIX | > > |Router#1|--------->|Mediator|---+ > > | | | | | > > '--------' '--------' | .---------. > > IP:10.1.1.1 IP:10.1.1.3 '----->| | > > ODID:10 ODID:0 |Collector| > > +----->| | > > .--------. | '---------' > > |IPFIX | | > > |Router#2|-----------------------' > > | | > > '--------' > > IP:10.1.1.2 > > ODID:20 > > > > Figure B: Loss of Observation Point Information. > > In some cases, e.g. masquerading, it might be desired to drop OD > information ;) > Yes. It depends on the configuration policy. > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 15] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 5.2. Loss of Base Time Information > > > > > > The Export Time field included in the IPFIX header indicates the base > > time for Flow Records. In IPFIX Information Elements, described in > > [RFC5102], there are delta time fields that indicate the time > > difference from the value of the Export Time field. If the Flow > > Records include any delta time fields and the IPFIX Mediator > > overwrites the Export Time field when sending IPFIX messages, the > > delta time fields become meaningless and, because Collectors can not > > recognize this situation, wrong time values are propagated. > > In the described case, the delta time fields contain wrong values > regardless of whether the Collector recognizes this situation or not! > I will remove "because Collectors can not recognize this situation". > > > > 5.3. Loss of Option Template Information > > > > > > In some cases, depending on the implementation of the IPFIX > > Mediators, the information that is reported by the Option Templates > > could also be lost. If, for example, the sampling rate is not > > communicated to the Collectors, a Collector would miscalculate the > > traffic volume. This might bring crucial problems. Even if an IPFIX > > Mediator were to simply relay received Option Template Information, > > "was to" > > > the value of its scope fields would become meaningless in the context > > "could become" > > > of a different session. It should be noted that the minimal > > information to be communicated by an IPFIX Mediator needs to be > > defined. > > remove "it should be noted that" > > > > > 5.4. Observation Domain ID and Template ID Management > > > > > > The Observation Domain ID is locally unique to the Exporting Process > > in an IPFIX Mediator, just like the Template ID is unique on the > > basis of the Observation Domain ID. These renewed identifiers should > > Be careful with repeating incomplete RFC5101 specs. Template IDs are > unique per Transport Session! I will improve it. > > > be managed using the Transport Session Information of the Collecting > > Process. If IPFIX Mediators could not manage the relations among > > "were not able to" > > > these identifiers and the received Transport Session Information, the > > Mediators would, for example, relay wrong values for the scope fields > > of the Option Template and for a "Template Withdraw Message". In > > You assume that the Template ID is in the Option's scope. That does not > have to be the case. > Generally, Template ID is used as the Option's scope. > > most cases, a Collector would not be able to interpret the Template > > ID of a "Template Withdraw Message" and the scope fields of an Option > > Template. The Collector would then shut down the IPFIX Session. > > > > 5.5. Transport Sessions Management > > > > > > How an IPFIX Mediator maintains relationships between the Transport > > Sessions of Collecting Processes and of Exporting Processes depends > > on its implementation. If multiple Transport Sessions of the > > Collecting Process are relayed to single Transport Session of the > > Exporting Process and the IPFIX Mediators shuts down the Transport > > Session of the Exporting Process, Flow Records on other Transport > > Sessions of the Collecting Processes would not be relayed at all. In > > the case of resetting a session of the Collecting Process, the > > I do not see a problem here. Outgoing transport session and incoming > transport sessions should be independent and configurable. There is no > automatism to shut down an outgoing session because an incoming session > closes. > It shows the possible problems. If outgoing transport session and incoming transport sessions should be independent and configurable, a problem do not happen. Certainly, Yes. I intended that outgoing transport session and incoming transport sessions should be independent in any case. Um, this subsection seems to be removed. > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 16] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > behavior of the IPFIX Mediator needs to be defined. > > > > > > .--------. > > |IPFIX | > > |Router#1|----+ > > | | | > > '--------' X > > .--------. | .--------. .---------. > > |IPFIX | '---->|IPFIX | | | > > |Router#2|--------->|Mediator|----X---->|Collector| > > | | +---->| | | | > > '--------' | '--------' '---------' > > .--------. | > > |IPFIX | | > > |Router#3|----' > > | | > > '--------' > > > > Figure C: Relaying from Multiple Transport Sessions to Single > > Transport Session. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 17] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 6. Conclusion > > > > > > This document has covered the applicability of IPFIX Mediation and a > > multitude of problems related to the implementation of IPFIX > > Mediators. To assist the ability of the Exporters and Collectors, it > > should be noted that there are various IPFIX Mediation functions for > > the operators to select from. Examples of the applicability of IPFIX > > Mediation are as follows. > > > > o Regarding IPFIX Exporting across domains, IPFIX Masquerading > > Proxies help operators to anonymize or filter Flow Records/Packet > > Reports, preventing privacy violations. > > > > o Regarding data retention, IPFIX Mediators enhance the storage of > > the measurement system. > > > > o Regarding interoperability, IPFIX Proxies provide interoperability > > between legacy protocols and IPFIX, even during the migration > > period to IPFIX. > > > > o Regarding the Flow-based Collector Selection function, in > > integrated networks, which mix MPLS VPN and IPv4/IPv6, this could > > be utilized more frequently. More sophisticated implementation > > methods would enhance the effectiveness. > > > > o Regarding scalability in large-scale networks, IPFIX Concentrators > > or IPFIX Distributors help to achieve high sample rates and fine- > > grained Flow analysis even as networks grow. As IPFIX Mediation > > functions, Flow selection sampling, aggregation and composition > > are beneficial. > > > > As a result, the benefits of IPFIX Mediation become apparent. > > However, there are still some open issues. > > > > o With the use of IPFIX Mediators, both Observation Point and IPFIX > > header information, such as the Exporter IP address, Observation > > Domain ID, and Export Time field, might be lost. This data should > > therefore be communicated between the Original Exporter and > > Collector via the IPFIX Mediator. > > > > o With the use of IPFIX Mediators, data advertised by Option > > Templates from the Original Exporter, such as the sampling rate > > and sampling algorithm used, might be lost. If a Collector is not > > informed of current sampling rates, traffic information might > > become worthless. > > > > o IPFIX Mediators are required to manage Transport Sessions, > > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 18] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > IPFIX messages could be created. > > > > These problems stem from the fact that no standards regarding IPFIX > > Mediation have been set. In particular, the minimum set of > > information which should be communicated between Original Exporters > > and Collectors, interworking between different IPFIX Transport > > Sessions, and the internal components of IPFIX Mediators should be > > standardized. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires March 30, 2009 [Page 19] > > > > Internet-Draft Mediation Problem Statement September 2008 > > > > > > 7. Security Considerations > > > > > > A flow-based measurement system might lead to privacy violations, > > such as the export of Flow Records to an outside address, if the > > system is not confined to the large-scale network under observation. > > General security issues of the IPFIX protocol are covered by the > > security considerations section in [RFC5101]. Security MUST be > > considered if different networks exchange Flow information. As the > > security of the exchange relies mostly on the protocol used, UDP does > > not seem appropriate for the exchange of information between > > networks. > > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 19 01:00:19 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2273A6B6B; Wed, 19 Nov 2008 01:00:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3C53A6B6C for ; Wed, 19 Nov 2008 01:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29rIA4TJg1ub for ; Wed, 19 Nov 2008 01:00:18 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id DE5783A67F5 for ; Wed, 19 Nov 2008 01:00:17 -0800 (PST) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id E34434950; Wed, 19 Nov 2008 10:00:14 +0100 (MET) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id AEA63B0030; Wed, 19 Nov 2008 10:00:14 +0100 (CET) Message-ID: <4923D59E.7010209@informatik.uni-erlangen.de> Date: Wed, 19 Nov 2008 10:00:14 +0100 From: Christoph Sommer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080925 Lightning/0.9 Thunderbird/2.0.0.17 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Atsushi Kobayashi References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> In-Reply-To: <20081119003311.E5B7.17391CF2@nttv6.net> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> IPFIX Mediator Problem statement wrote: >>> IPFIX Mediation is an additional function to suit the needs of some >>> measurement system. >> >> Isn't IPFIX Mediation supposed to be an umbrella term which includes >> IPFIX concentrators and IPFIX proxies? > > I mean that IPFIX Mediator is umbrella term which includes IPFIX > concentrators and IPFIX proxies. But, IPFIX Mediation is not. I think there is still some confusion on what a number of terms that came up during IPFIX Mediator discussions mean. Some of them are not clearly defined and some are used interchangeably. From the top of my head, these are: * IPFIX Mediator * IPFIX Mediation * IPFIX Mediation device * Mediation Function * Intermediate Function * Intermediate Process * Exporter with Mediation Function * Exporter with Mediation How about we settle on a subset and give a clear(er) definition of these terms? I propose the following two definitions: * Intermediate Process: a black box that processes Flow Records, i.e. that takes Flow Records as its input and has Flow Records as its output. * IPFIX Mediator: a device that can host zero or more Intermediate Processes along with other Processes defined in IPFIX. I think these two definitions can be used to describe all currently-thought-of IPFIX Mediators by using zero or more Intermediate Processes (IMPs), like so: * IPFIX Proxy: Collector---Exporter * IPFIX Concentrator: Collector---"IMP Aggregator"---Exporter * IPFIX Distributor: Collector---"IMP Distributor"---Exporter(s) * IPFIX Masquerading Proxy: Collector---"IMP Masquerade"---Exporter I would like to hear as many comments/suggestions as possible, so we can arrive at a clear definition of what an IPFIX Mediator is and what an Intermediate Process can do! Regards, Christoph -- Christoph Sommer Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 http://www7.informatik.uni-erlangen.de/~sommer/ _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 19 01:00:19 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F2273A6B6B; Wed, 19 Nov 2008 01:00:19 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3C53A6B6C for ; Wed, 19 Nov 2008 01:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29rIA4TJg1ub for ; Wed, 19 Nov 2008 01:00:18 -0800 (PST) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id DE5783A67F5 for ; Wed, 19 Nov 2008 01:00:17 -0800 (PST) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id E34434950; Wed, 19 Nov 2008 10:00:14 +0100 (MET) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id AEA63B0030; Wed, 19 Nov 2008 10:00:14 +0100 (CET) Message-ID: <4923D59E.7010209@informatik.uni-erlangen.de> Date: Wed, 19 Nov 2008 10:00:14 +0100 From: Christoph Sommer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080925 Lightning/0.9 Thunderbird/2.0.0.17 ThunderBrowse/3.2.2.1 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Atsushi Kobayashi References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> In-Reply-To: <20081119003311.E5B7.17391CF2@nttv6.net> X-Enigmail-Version: 0.95.0 Cc: IETF IPFIX Working Group Subject: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear all, Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> IPFIX Mediator Problem statement wrote: >>> IPFIX Mediation is an additional function to suit the needs of some >>> measurement system. >> >> Isn't IPFIX Mediation supposed to be an umbrella term which includes >> IPFIX concentrators and IPFIX proxies? > > I mean that IPFIX Mediator is umbrella term which includes IPFIX > concentrators and IPFIX proxies. But, IPFIX Mediation is not. I think there is still some confusion on what a number of terms that came up during IPFIX Mediator discussions mean. Some of them are not clearly defined and some are used interchangeably. From the top of my head, these are: * IPFIX Mediator * IPFIX Mediation * IPFIX Mediation device * Mediation Function * Intermediate Function * Intermediate Process * Exporter with Mediation Function * Exporter with Mediation How about we settle on a subset and give a clear(er) definition of these terms? I propose the following two definitions: * Intermediate Process: a black box that processes Flow Records, i.e. that takes Flow Records as its input and has Flow Records as its output. * IPFIX Mediator: a device that can host zero or more Intermediate Processes along with other Processes defined in IPFIX. I think these two definitions can be used to describe all currently-thought-of IPFIX Mediators by using zero or more Intermediate Processes (IMPs), like so: * IPFIX Proxy: Collector---Exporter * IPFIX Concentrator: Collector---"IMP Aggregator"---Exporter * IPFIX Distributor: Collector---"IMP Distributor"---Exporter(s) * IPFIX Masquerading Proxy: Collector---"IMP Masquerade"---Exporter I would like to hear as many comments/suggestions as possible, so we can arrive at a clear definition of what an IPFIX Mediator is and what an Intermediate Process can do! Regards, Christoph -- Christoph Sommer Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 http://www7.informatik.uni-erlangen.de/~sommer/ _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 19 08:38:27 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4094D3A6A9E; Wed, 19 Nov 2008 08:38:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA403A6A9E for ; Wed, 19 Nov 2008 08:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAvZG0kqyo8m for ; Wed, 19 Nov 2008 08:38:24 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 587BE3A6A91 for ; Wed, 19 Nov 2008 08:38:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B9B6DD93A3; Wed, 19 Nov 2008 17:38:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sbpf0TaVq+lc; Wed, 19 Nov 2008 17:38:21 +0100 (MET) Received: from [130.129.95.36] (unknown [130.129.95.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 81087D93A2; Wed, 19 Nov 2008 17:38:20 +0100 (MET) Message-Id: From: Brian Trammell To: Christoph Sommer In-Reply-To: <4923D59E.7010209@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:38:18 -0600 References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.929.2) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Cristoph, all: In short, yes. In more detail, inline, below. On Nov 19, 2008, at 3:00 AM, Christoph Sommer wrote: > I propose the following two definitions: > > * Intermediate Process: > a black box that processes Flow Records, i.e. that takes > Flow Records as its input and has Flow Records as its output. Crucial here is "Flow Records", as in the same output of a Metering Process, not necessarily IPFIX-encoded, as this allows the V5->IPFIX and V9->IPFIX mediators. > > * IPFIX Mediator: > a device that can host zero or more Intermediate Processes > along with other Processes defined in IPFIX. Yep. I presume a mediator with zero intermediates would be used for low-tech NAT traversal, transport protocol isolation, or transport protocol/security layer translation? > I think these two definitions can be used to describe all > currently-thought-of IPFIX Mediators by using zero or more > Intermediate > Processes (IMPs), like so: > > * IPFIX Proxy: > Collector---Exporter > > From ipfix-bounces@ietf.org Wed Nov 19 08:38:27 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4094D3A6A9E; Wed, 19 Nov 2008 08:38:27 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA403A6A9E for ; Wed, 19 Nov 2008 08:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAvZG0kqyo8m for ; Wed, 19 Nov 2008 08:38:24 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 587BE3A6A91 for ; Wed, 19 Nov 2008 08:38:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B9B6DD93A3; Wed, 19 Nov 2008 17:38:21 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sbpf0TaVq+lc; Wed, 19 Nov 2008 17:38:21 +0100 (MET) Received: from [130.129.95.36] (unknown [130.129.95.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 81087D93A2; Wed, 19 Nov 2008 17:38:20 +0100 (MET) Message-Id: From: Brian Trammell To: Christoph Sommer In-Reply-To: <4923D59E.7010209@informatik.uni-erlangen.de> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 10:38:18 -0600 References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.929.2) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Cristoph, all: In short, yes. In more detail, inline, below. On Nov 19, 2008, at 3:00 AM, Christoph Sommer wrote: > I propose the following two definitions: > > * Intermediate Process: > a black box that processes Flow Records, i.e. that takes > Flow Records as its input and has Flow Records as its output. Crucial here is "Flow Records", as in the same output of a Metering Process, not necessarily IPFIX-encoded, as this allows the V5->IPFIX and V9->IPFIX mediators. > > * IPFIX Mediator: > a device that can host zero or more Intermediate Processes > along with other Processes defined in IPFIX. Yep. I presume a mediator with zero intermediates would be used for low-tech NAT traversal, transport protocol isolation, or transport protocol/security layer translation? > I think these two definitions can be used to describe all > currently-thought-of IPFIX Mediators by using zero or more > Intermediate > Processes (IMPs), like so: > > * IPFIX Proxy: > Collector---Exporter > * IPFIX Concentrator: > Collector---"IMP Aggregator"---Exporter > > * IPFIX Distributor: > Collector---"IMP Distributor"---Exporter(s) > > * IPFIX Masquerading Proxy: > Collector---"IMP Masquerade"---Exporter (btw, I like the "IMP" notation, because "IP" would be confusing. How about "ImP" though, as it's two words, not three?) Of course we should note that you can chain intermediate processes arbitrarily: IPFIX redistributing anonymizing aggregator: Collector --- "ImP Aggregator" --- "ImP Anonymizer" --- "ImP Distributor" --- Exporter(s) > I would like to hear as many comments/suggestions as possible, so we > can > arrive at a clear definition of what an IPFIX Mediator is and what an > Intermediate Process can do! > > > Regards, > > Christoph > > -- > Christoph Sommer > Computer Networks and Communication Systems > University of Erlangen-Nuremberg, Germany > Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 > http://www7.informatik.uni-erlangen.de/~sommer/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix > * IPFIX Concentrator: > Collector---"IMP Aggregator"---Exporter > > * IPFIX Distributor: > Collector---"IMP Distributor"---Exporter(s) > > * IPFIX Masquerading Proxy: > Collector---"IMP Masquerade"---Exporter (btw, I like the "IMP" notation, because "IP" would be confusing. How about "ImP" though, as it's two words, not three?) Of course we should note that you can chain intermediate processes arbitrarily: IPFIX redistributing anonymizing aggregator: Collector --- "ImP Aggregator" --- "ImP Anonymizer" --- "ImP Distributor" --- Exporter(s) > I would like to hear as many comments/suggestions as possible, so we > can > arrive at a clear definition of what an IPFIX Mediator is and what an > Intermediate Process can do! > > > Regards, > > Christoph > > -- > Christoph Sommer > Computer Networks and Communication Systems > University of Erlangen-Nuremberg, Germany > Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 > http://www7.informatik.uni-erlangen.de/~sommer/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 19 11:29:07 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBD028C1AC; Wed, 19 Nov 2008 11:29:07 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9E03A697D for ; Wed, 19 Nov 2008 11:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edh4Rk-8DsN5 for ; Wed, 19 Nov 2008 11:29:04 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 3834B3A63EB for ; Wed, 19 Nov 2008 11:29:00 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 4A4F4474AA; Wed, 19 Nov 2008 20:28:40 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3B35F2A51; Wed, 19 Nov 2008 20:28:40 +0100 (CET) Message-ID: <492468F1.8050606@net.in.tum.de> Date: Wed, 19 Nov 2008 20:28:49 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> In-Reply-To: <20081119003311.E5B7.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769214606==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1769214606== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040101010700000801000101" This is a cryptographically signed message in MIME format. --------------ms040101010700000801000101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> For me, the purpose of the draft is not quite clear. Is it to justify >> the need of IPFIX Mediators? Then, the focus should be more on >> monitoring situations that cannot be adequately handled without this >> intermediate box between exporters and collectors. >=20 > This draft covers the possible examples related to Mediation, > and some problems that IPFIX mediator will face in future. Hm. In my opinion, "problem statement" refers to the problems we want to solve with Mediation, not to problems we will have because of Mediation. > For me, some of applicable examples shows vital function, such as "IPFI= X > Export Across Domains" or "Interoperability between Legacy Protocols an= d > IPFIX". > I think that it is better to gather other applicable examples than > focusing on vital functions in order to show the effectiveness of > mediator.=20 >=20 > So, I am wondering if some applicable examples should be removed or if > other more vital examples should be added. What do you think? I think it is ok to discuss what is possible without Mediation and to show the limits of "state-of-the-art" IPFIX. So, you could - present a problem, - show how the problem could be solved without mediation (if possible), - argue why this solution is not optimal, and - present how mediation enables a better solution. >> If functionalities like configurable flow keys, flow selection, >> anonymization are realized on an IPFIX exporter directly, they can be >> considered as part of the Metering Process. So, there is no mediation >> involved. >> >=20 > Certainly, some of mediation function can be considered as part of > Metering Process. But, maintaining Flow Records is main task of Meterin= g > Process. >=20 > Other functions, such as anonymization or flow selection, are not > limited to be included in Metering Process. For example, I can think > that the general Metering Process in interface module can create Flow > Records, and then Mediation in main cpu module can anonymize them. >=20 > Therefore, locating "mediation" in any devices can be utilized. Ok. > Please see following text regarding other comments. See some comments below. Regards, Gerhard >>> network monitoring usages. The sharing of flow-based information >>> among orthogonal monitoring applications raises open issues in ter= ms >> not sure what you mean by "orthogonal" >> >=20 > The requirement of several applications in same network could be > orthogonal as following. > - Granularity of Flow Records: coarse-grained or fine-grained. > - Time of period for storage: long-term or short-term. > - Traceability: anonymization or not. >=20 > These situation could not be compatible without mediation. > I will consider more about this sentence. Ok. So the requirements are orthogonal, not the applications themselves. Maybe you find a better word for "orthogonal". >>> 1. Introduction >>> >>> >>> While the IPFIX requirements defined in [RFC3917] mention an >>> intermediate function, such as an IPFIX Proxy or an Concentrator, >> "...mention intermediate functions, such as IPFIX proxies and IPFIX >> concentrators [not sure if these terms should start with capital >> letters],..." >> >=20 > Do you mean the capital letters are not allowed to be used before termi= nology > section? Forget about my comment. It's just that Concentrator has not yet been a fixed term in any IPFIX document. But as you introduce it in the terminology section, it's ok. >>> 2. Terminology and Definition >>> >>> >>> The terms in this section are in line with those in the IPFIX >>> specification document [RFC5101] and the PSAMP specification docum= ent >>> [I-D.ietf-psamp-protocol]. Additional terms required for the IPFI= X >> What do you mean by "inline"? >> If you reuse terms from RFC5101, then you do not have to repeat them >> here. Only additional terms should appear in this section. Otherwise i= t >> is not clear which terms are new. >> >=20 > At first, I added terms from RFC5101 to make it easy-to-understand for > first IPFIX reader. But, it does not clear whether there is a differenc= e > between original term, even if same. >=20 > I will improve the following description. >=20 > Flow Key [RFC5101] >=20 > Flow Record [RFC5101] >=20 > Observation Point [RFC5101] >=20 > Exporter [RFC5101] >=20 > Collector [RFC5101] The question if we should repeat terms in every terminology sections arises with every new draft ;) IMO, it is necessary to put the readers attention to the new terms, maybe by moving them in on subsection "new terms". Old terms may be repeated in another subsection. Be careful with redefining terms from a standard track document! >>> IPFIX Mediation can be included in any devices, such as routers= , >>> switches, NMS(Network Management Systems), or be deployed in >>> stand-alone devices. >> I'm not sure. I would rather restrict IPFIX Mediation functions to IPF= IX >> Mediators. If performed on the original exporter, we already do have t= he >> Metering Process which can do all these things. >> >=20 > I can image that IPFIX Mediation function is located between Metering > and Exporting Process. Ok. >>> IPFIX Mediator >>> >>> An IPFIX Mediator contains one or more functions defined in IPF= IX >> "one or more IPFIX Mediation functions" >> >>> Mediation. The IPFIX Mediator can be a stand-alone or a virtua= l >>> device. It also contains one or more Collecting Processes and = one >> What do you mean by "virtual"? >> >=20 > If IPFIX Mediator and Exporter are located in same device, IPFIX > Mediator is virtual device rather than stand-alone. > I would not rather restrict possible implementations. Two possibilities: - remove the sentence - explain a little bit further what you mean by "virtual" >>> IPFIX Proxy >>> >>> An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Message= s >>> from Original Exporter, and sends IPFIX Messages to one or more= >> It is possible that an IPFIX Proxy receives IPFIX Messages from an IPF= IX >> Mediator? >=20 > Yes. I would not rather restrict it. I need to improve them. >=20 >> Sending to multiple Collectors requires "replication" of IPFIX Message= s, >> which implies that the included records are replicated as well. >=20 > Yes. >> You mention "replication" in the case of IPFIX Distributor below. Mayb= e >> you want to mention it here as well? >=20 > No. As you mentioned below, I mean IPFIX Distributor replicates Records= =2E Ok. You still could mention that the IPFIX Proxy duplicates Messages if they are sent to multiple Collectors. >> What is the difference between IPFIX Proxy and IPFIX Distributor? >> Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX= >> Distributor handles individual records? >> >=20 > Yes. Maybe you can clarify this in the text. >>> IPFIX Masquerading Proxy >>> >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that screens o= ut >>> a part of data of input Flow Records/Packet Reports according t= o >>> configured policies. It can thus, for example, hide the networ= k >>> topology information or customers' IP addresses. >> Note: If you call this a "proxy", then my above distinction between >> IPFIX Proxy and IPFIX Distributor does not work. >=20 > Is it strange that IPFIX Masquerading Proxy handles Records, > although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handle= s > Records? At least, it's a bit confusing. Alternatively, you could forget about the "IPFIX Distributor" and call it "IPFIX Proxy" as well because there is no real difference between IPFIX Proxy and IPFIX Distributor. If a Proxy is used to translate Netflow into IPFIX, it also has to change the messages and maybe the Records. >> 3.2. Data Retention >>> >>> >>> Data retention refers to the storage of traffic data by service >>> providers and commercial organizations. According to European >>> Commission directives, operators are required to retain both IP an= d >>> voice traffic data, in wired and wireless networks, generated by e= nd >>> users while using a service provider's services. The goal of data= >>> retention is to ensure that call detail records and Flow Records a= re >>> available for the purpose of detection, investigation, and >>> prosecution of serious crimes, if necessary. The European Commiss= ion >>> directives define the following data retention services: >>> >>> o Fixed telephony (includes fixed voice, voicemail, and conferenc= e >>> and data calls) >>> >>> o Mobile telephony (includes mobile voice, voicemail, conference = and >>> data calls, SMS, and MMS) >>> >>> o Internet telephony (includes every multimedia session associate= d >>> with IP multimedia services) >>> >>> o Internet e-mail >>> >>> o Internet access >>> >>> By monitoring Flow Records, IPFIX can fulfill these requirements o= f >>> Internet access services. >> Ok, but where is the link to IPFIX Mediation? >> >=20 > It is possible examples. IPFIX Mediation with storage allow collection > system to become huge storage to suit data retention. Ok. You might add a sentence saying that mediation (e.g. IPFIX distributor) is needed to handle the flow data required by these regulations. >>> Metering Process allows operators to specify their own set of Flow= >>> Keys and extra Information Elements in the Template Record. >>> Specifically, Original Exporters classify the Flow Records by thei= r >>> contents, and then aggregate them with appropriate Flow keys based= on >> You assume one specific implementation where the Metering Process firs= t >> produces IP-quintuple Flows which are then aggregated. However, it is >> also possible to directly generate Flows with Flow Key fields differin= g >> from the usual IP-quintuple. In this case, it is not an IPFIX Mediatio= n >> function but just a Metering Process. Also, I would not call this case= >> flow "aggregation". >> >=20 > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And > then, Metering Process can create aggregated Flow Records without > Mediation. >=20 > But, in some case, Metering Process in port module creates IP-quintuple= > Flow and then mediation function in main cpu creates aggregated Flow. Ok. So you might add that this solution is useful in the case where unconfigurable MPs creating IP-quintuple flow records exist. >>> another for capacity planning, and so on. The content and >>> granularity of the Flow can satisfy the requirements of each >>> Collector with a specific application. >>> >>> On one hand, this optimizes the Metering Process, because only Flo= ws >>> of interest are looked at. On the other hand, it optimizes the >>> Exporting Process, because only the information of interest is >>> exported. Finally, this reduces load of the Collecting Process as= >>> less Flow Records are handled, and Flow Record filtering and >>> aggregating are required. >> Ok. So this subsection proposed a solution that works without IPFIX >> Mediation. >> >=20 > Yes... >=20 > I write down several solution against the large traffic volume in the > sections regardless of whether using Mediation or not. > Does it confuse you? You could distinguish visibly between solutions not requiring Mediation and solutions that work with Mediation only. >>> these identifiers and the received Transport Session Information, = the >>> Mediators would, for example, relay wrong values for the scope fie= lds >>> of the Option Template and for a "Template Withdraw Message". In >> You assume that the Template ID is in the Option's scope. That does no= t >> have to be the case. >> >=20 > Generally, Template ID is used as the Option's scope. Hm, no. Have a look at: http://tools.ietf.org/html/rfc5101#section-4 Only the Flow Keys Option contains the Temlate ID. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040101010700000801000101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExOTE5Mjg0OVowIwYJKoZIhvcNAQkEMRYEFD6KsgohaXuN +B3PTPebGjO9lFUaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQC2PeYDIzjtbOFK7enn9ncN1kXe0Ra45hD6BmOyhb9Ud1FpgC9/y+lpaIpv RLUl/wQLqCeJX06LY8hlr6TrxVWfEf+YC9LixmX1fVN5xhDgXts4TGx0FXGyvM/5VGMOrdR9 ODUSe2h91I3CjVBcq2nMDnkiwhnJ2yluicxTFvOYOVHIl4sFll9Bocg66TMz2YWesb58HhkN ZeaepzPQhJQ3qK1ChAV6kNohdi5i9j5W8S2NZ3JDEyVhdRTSDgTVYWaPw9CymQUI9VkONTbM Lnej/b/nRCKGAI7vMK48HS7pb8i16HCC8DZ4MGCLmPGkuJIB5uqL7Nbh+i5Hd8MxOVO0AAAA AAAA --------------ms040101010700000801000101-- --===============1769214606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1769214606==-- From ipfix-bounces@ietf.org Wed Nov 19 11:29:07 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBD028C1AC; Wed, 19 Nov 2008 11:29:07 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9E03A697D for ; Wed, 19 Nov 2008 11:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edh4Rk-8DsN5 for ; Wed, 19 Nov 2008 11:29:04 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 3834B3A63EB for ; Wed, 19 Nov 2008 11:29:00 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 4A4F4474AA; Wed, 19 Nov 2008 20:28:40 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3B35F2A51; Wed, 19 Nov 2008 20:28:40 +0100 (CET) Message-ID: <492468F1.8050606@net.in.tum.de> Date: Wed, 19 Nov 2008 20:28:49 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Atsushi Kobayashi References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> In-Reply-To: <20081119003311.E5B7.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769214606==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1769214606== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040101010700000801000101" This is a cryptographically signed message in MIME format. --------------ms040101010700000801000101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> For me, the purpose of the draft is not quite clear. Is it to justify >> the need of IPFIX Mediators? Then, the focus should be more on >> monitoring situations that cannot be adequately handled without this >> intermediate box between exporters and collectors. >=20 > This draft covers the possible examples related to Mediation, > and some problems that IPFIX mediator will face in future. Hm. In my opinion, "problem statement" refers to the problems we want to solve with Mediation, not to problems we will have because of Mediation. > For me, some of applicable examples shows vital function, such as "IPFI= X > Export Across Domains" or "Interoperability between Legacy Protocols an= d > IPFIX". > I think that it is better to gather other applicable examples than > focusing on vital functions in order to show the effectiveness of > mediator.=20 >=20 > So, I am wondering if some applicable examples should be removed or if > other more vital examples should be added. What do you think? I think it is ok to discuss what is possible without Mediation and to show the limits of "state-of-the-art" IPFIX. So, you could - present a problem, - show how the problem could be solved without mediation (if possible), - argue why this solution is not optimal, and - present how mediation enables a better solution. >> If functionalities like configurable flow keys, flow selection, >> anonymization are realized on an IPFIX exporter directly, they can be >> considered as part of the Metering Process. So, there is no mediation >> involved. >> >=20 > Certainly, some of mediation function can be considered as part of > Metering Process. But, maintaining Flow Records is main task of Meterin= g > Process. >=20 > Other functions, such as anonymization or flow selection, are not > limited to be included in Metering Process. For example, I can think > that the general Metering Process in interface module can create Flow > Records, and then Mediation in main cpu module can anonymize them. >=20 > Therefore, locating "mediation" in any devices can be utilized. Ok. > Please see following text regarding other comments. See some comments below. Regards, Gerhard >>> network monitoring usages. The sharing of flow-based information >>> among orthogonal monitoring applications raises open issues in ter= ms >> not sure what you mean by "orthogonal" >> >=20 > The requirement of several applications in same network could be > orthogonal as following. > - Granularity of Flow Records: coarse-grained or fine-grained. > - Time of period for storage: long-term or short-term. > - Traceability: anonymization or not. >=20 > These situation could not be compatible without mediation. > I will consider more about this sentence. Ok. So the requirements are orthogonal, not the applications themselves. Maybe you find a better word for "orthogonal". >>> 1. Introduction >>> >>> >>> While the IPFIX requirements defined in [RFC3917] mention an >>> intermediate function, such as an IPFIX Proxy or an Concentrator, >> "...mention intermediate functions, such as IPFIX proxies and IPFIX >> concentrators [not sure if these terms should start with capital >> letters],..." >> >=20 > Do you mean the capital letters are not allowed to be used before termi= nology > section? Forget about my comment. It's just that Concentrator has not yet been a fixed term in any IPFIX document. But as you introduce it in the terminology section, it's ok. >>> 2. Terminology and Definition >>> >>> >>> The terms in this section are in line with those in the IPFIX >>> specification document [RFC5101] and the PSAMP specification docum= ent >>> [I-D.ietf-psamp-protocol]. Additional terms required for the IPFI= X >> What do you mean by "inline"? >> If you reuse terms from RFC5101, then you do not have to repeat them >> here. Only additional terms should appear in this section. Otherwise i= t >> is not clear which terms are new. >> >=20 > At first, I added terms from RFC5101 to make it easy-to-understand for > first IPFIX reader. But, it does not clear whether there is a differenc= e > between original term, even if same. >=20 > I will improve the following description. >=20 > Flow Key [RFC5101] >=20 > Flow Record [RFC5101] >=20 > Observation Point [RFC5101] >=20 > Exporter [RFC5101] >=20 > Collector [RFC5101] The question if we should repeat terms in every terminology sections arises with every new draft ;) IMO, it is necessary to put the readers attention to the new terms, maybe by moving them in on subsection "new terms". Old terms may be repeated in another subsection. Be careful with redefining terms from a standard track document! >>> IPFIX Mediation can be included in any devices, such as routers= , >>> switches, NMS(Network Management Systems), or be deployed in >>> stand-alone devices. >> I'm not sure. I would rather restrict IPFIX Mediation functions to IPF= IX >> Mediators. If performed on the original exporter, we already do have t= he >> Metering Process which can do all these things. >> >=20 > I can image that IPFIX Mediation function is located between Metering > and Exporting Process. Ok. >>> IPFIX Mediator >>> >>> An IPFIX Mediator contains one or more functions defined in IPF= IX >> "one or more IPFIX Mediation functions" >> >>> Mediation. The IPFIX Mediator can be a stand-alone or a virtua= l >>> device. It also contains one or more Collecting Processes and = one >> What do you mean by "virtual"? >> >=20 > If IPFIX Mediator and Exporter are located in same device, IPFIX > Mediator is virtual device rather than stand-alone. > I would not rather restrict possible implementations. Two possibilities: - remove the sentence - explain a little bit further what you mean by "virtual" >>> IPFIX Proxy >>> >>> An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Message= s >>> from Original Exporter, and sends IPFIX Messages to one or more= >> It is possible that an IPFIX Proxy receives IPFIX Messages from an IPF= IX >> Mediator? >=20 > Yes. I would not rather restrict it. I need to improve them. >=20 >> Sending to multiple Collectors requires "replication" of IPFIX Message= s, >> which implies that the included records are replicated as well. >=20 > Yes. >> You mention "replication" in the case of IPFIX Distributor below. Mayb= e >> you want to mention it here as well? >=20 > No. As you mentioned below, I mean IPFIX Distributor replicates Records= =2E Ok. You still could mention that the IPFIX Proxy duplicates Messages if they are sent to multiple Collectors. >> What is the difference between IPFIX Proxy and IPFIX Distributor? >> Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX= >> Distributor handles individual records? >> >=20 > Yes. Maybe you can clarify this in the text. >>> IPFIX Masquerading Proxy >>> >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that screens o= ut >>> a part of data of input Flow Records/Packet Reports according t= o >>> configured policies. It can thus, for example, hide the networ= k >>> topology information or customers' IP addresses. >> Note: If you call this a "proxy", then my above distinction between >> IPFIX Proxy and IPFIX Distributor does not work. >=20 > Is it strange that IPFIX Masquerading Proxy handles Records, > although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handle= s > Records? At least, it's a bit confusing. Alternatively, you could forget about the "IPFIX Distributor" and call it "IPFIX Proxy" as well because there is no real difference between IPFIX Proxy and IPFIX Distributor. If a Proxy is used to translate Netflow into IPFIX, it also has to change the messages and maybe the Records. >> 3.2. Data Retention >>> >>> >>> Data retention refers to the storage of traffic data by service >>> providers and commercial organizations. According to European >>> Commission directives, operators are required to retain both IP an= d >>> voice traffic data, in wired and wireless networks, generated by e= nd >>> users while using a service provider's services. The goal of data= >>> retention is to ensure that call detail records and Flow Records a= re >>> available for the purpose of detection, investigation, and >>> prosecution of serious crimes, if necessary. The European Commiss= ion >>> directives define the following data retention services: >>> >>> o Fixed telephony (includes fixed voice, voicemail, and conferenc= e >>> and data calls) >>> >>> o Mobile telephony (includes mobile voice, voicemail, conference = and >>> data calls, SMS, and MMS) >>> >>> o Internet telephony (includes every multimedia session associate= d >>> with IP multimedia services) >>> >>> o Internet e-mail >>> >>> o Internet access >>> >>> By monitoring Flow Records, IPFIX can fulfill these requirements o= f >>> Internet access services. >> Ok, but where is the link to IPFIX Mediation? >> >=20 > It is possible examples. IPFIX Mediation with storage allow collection > system to become huge storage to suit data retention. Ok. You might add a sentence saying that mediation (e.g. IPFIX distributor) is needed to handle the flow data required by these regulations. >>> Metering Process allows operators to specify their own set of Flow= >>> Keys and extra Information Elements in the Template Record. >>> Specifically, Original Exporters classify the Flow Records by thei= r >>> contents, and then aggregate them with appropriate Flow keys based= on >> You assume one specific implementation where the Metering Process firs= t >> produces IP-quintuple Flows which are then aggregated. However, it is >> also possible to directly generate Flows with Flow Key fields differin= g >> from the usual IP-quintuple. In this case, it is not an IPFIX Mediatio= n >> function but just a Metering Process. Also, I would not call this case= >> flow "aggregation". >> >=20 > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And > then, Metering Process can create aggregated Flow Records without > Mediation. >=20 > But, in some case, Metering Process in port module creates IP-quintuple= > Flow and then mediation function in main cpu creates aggregated Flow. Ok. So you might add that this solution is useful in the case where unconfigurable MPs creating IP-quintuple flow records exist. >>> another for capacity planning, and so on. The content and >>> granularity of the Flow can satisfy the requirements of each >>> Collector with a specific application. >>> >>> On one hand, this optimizes the Metering Process, because only Flo= ws >>> of interest are looked at. On the other hand, it optimizes the >>> Exporting Process, because only the information of interest is >>> exported. Finally, this reduces load of the Collecting Process as= >>> less Flow Records are handled, and Flow Record filtering and >>> aggregating are required. >> Ok. So this subsection proposed a solution that works without IPFIX >> Mediation. >> >=20 > Yes... >=20 > I write down several solution against the large traffic volume in the > sections regardless of whether using Mediation or not. > Does it confuse you? You could distinguish visibly between solutions not requiring Mediation and solutions that work with Mediation only. >>> these identifiers and the received Transport Session Information, = the >>> Mediators would, for example, relay wrong values for the scope fie= lds >>> of the Option Template and for a "Template Withdraw Message". In >> You assume that the Template ID is in the Option's scope. That does no= t >> have to be the case. >> >=20 > Generally, Template ID is used as the Option's scope. Hm, no. Have a look at: http://tools.ietf.org/html/rfc5101#section-4 Only the Flow Keys Option contains the Temlate ID. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040101010700000801000101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTExOTE5Mjg0OVowIwYJKoZIhvcNAQkEMRYEFD6KsgohaXuN +B3PTPebGjO9lFUaMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQC2PeYDIzjtbOFK7enn9ncN1kXe0Ra45hD6BmOyhb9Ud1FpgC9/y+lpaIpv RLUl/wQLqCeJX06LY8hlr6TrxVWfEf+YC9LixmX1fVN5xhDgXts4TGx0FXGyvM/5VGMOrdR9 ODUSe2h91I3CjVBcq2nMDnkiwhnJ2yluicxTFvOYOVHIl4sFll9Bocg66TMz2YWesb58HhkN ZeaepzPQhJQ3qK1ChAV6kNohdi5i9j5W8S2NZ3JDEyVhdRTSDgTVYWaPw9CymQUI9VkONTbM Lnej/b/nRCKGAI7vMK48HS7pb8i16HCC8DZ4MGCLmPGkuJIB5uqL7Nbh+i5Hd8MxOVO0AAAA AAAA --------------ms040101010700000801000101-- --===============1769214606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1769214606==-- From ipfix-bounces@ietf.org Wed Nov 19 12:36:06 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BA93A6BC9; Wed, 19 Nov 2008 12:36:06 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628653A6BC9 for ; Wed, 19 Nov 2008 12:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5GRdKv72I4J for ; Wed, 19 Nov 2008 12:36:03 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 33FFC28C200 for ; Wed, 19 Nov 2008 12:36:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6916D196F0; Thu, 20 Nov 2008 09:36:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX8P-bmmNj1n; Thu, 20 Nov 2008 09:36:00 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C75CB196EE; Thu, 20 Nov 2008 09:35:58 +1300 (NZDT) Message-ID: <492478A8.3030008@auckland.ac.nz> Date: Thu, 20 Nov 2008 09:35:52 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Content-Type: multipart/mixed; boundary="------------060007080305080701090800" Cc: IPFIX list Subject: [IPFIX] Writeups for IPFIX 'Exporting Types' and 'File Format' X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --------------060007080305080701090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan: Following up on this morning's IPFIX meeting, here are the writeups for these two drafts. Please have a look at them; if they're OK, please submit the two drafts to IESG for publication as RFCs. Cheers, nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand --------------060007080305080701090800 Content-Type: text/plain; name="export-type-info.writeup" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="export-type-info.writeup" Document: draft-ietf-ipfix-exporting-type-02.txt Title: Exporting Type Information for IPFIX Information Elements Editors: E. Boschi, B. Trammell, L. Mark, T. Zseby Intended status: Standards Track As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes are From ipfix-bounces@ietf.org Wed Nov 19 12:36:06 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BA93A6BC9; Wed, 19 Nov 2008 12:36:06 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628653A6BC9 for ; Wed, 19 Nov 2008 12:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5GRdKv72I4J for ; Wed, 19 Nov 2008 12:36:03 -0800 (PST) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by core3.amsl.com (Postfix) with ESMTP id 33FFC28C200 for ; Wed, 19 Nov 2008 12:36:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 6916D196F0; Thu, 20 Nov 2008 09:36:00 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX8P-bmmNj1n; Thu, 20 Nov 2008 09:36:00 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C75CB196EE; Thu, 20 Nov 2008 09:35:58 +1300 (NZDT) Message-ID: <492478A8.3030008@auckland.ac.nz> Date: Thu, 20 Nov 2008 09:35:52 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Content-Type: multipart/mixed; boundary="------------060007080305080701090800" Cc: IPFIX list Subject: [IPFIX] Writeups for IPFIX 'Exporting Types' and 'File Format' X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --------------060007080305080701090800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan: Following up on this morning's IPFIX meeting, here are the writeups for these two drafts. Please have a look at them; if they're OK, please submit the two drafts to IESG for publication as RFCs. Cheers, nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand --------------060007080305080701090800 Content-Type: text/plain; name="export-type-info.writeup" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="export-type-info.writeup" Document: draft-ietf-ipfix-exporting-type-02.txt Title: Exporting Type Information for IPFIX Information Elements Editors: E. Boschi, B. Trammell, L. Mark, T. Zseby Intended status: Standards Track As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes arexpected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Nevil Brownlee. I have reviewed this draft, I believe it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This is version 2 of the draft. It has had extensive review by the WG members, and by others from the PSAMP WG. These reviews seem sufficiently thorough to me. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The draft is concerned only with specifying a way to export data type information about IPFIX Information Elements, so that developers of Anaalysis tools for IPFIX data will have an effective way to handle non-standard Information Elements. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns for this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong consensus within the IPFIX Working Group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? idnits 2.10.02 says a. Change boilerplate to RFC 4748-style 16 Dec 08 is the 'required from' date b. One unused reference (to RFC5102) can be deleted c. Outdated reference to psamp-info-08 This draft is now in RFC Editor queue b. and c. can be fixed at Authors 48hr edits, a. could also be fixed that way if neccessary. The draft is IPFIX-centric, it needs no other formal checks. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these de expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Nevil Brownlee. I have reviewed this draft, I believe it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This is version 2 of the draft. It has had extensive review by the WG members, and by others from the PSAMP WG. These reviews seem sufficiently thorough to me. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The draft is concerned only with specifying a way to export data type information about IPFIX Information Elements, so that developers of Anaalysis tools for IPFIX data will have an effective way to handle non-standard Information Elements. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns for this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong consensus within the IPFIX Working Group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? idnits 2.10.02 says a. Change boilerplate to RFC 4748-style 16 Dec 08 is the 'required from' date b. One unused reference (to RFC5102) can be deleted c. Outdated reference to psamp-info-08 This draft is now in RFC Editor queue b. and c. can be fixed at Authors 48hr edits, a. could also be fixed that way if neccessary. The draft is IPFIX-centric, it needs no other formal checks. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split. No, now that psamp-info is in RFC EDitor queue, all the normative reference RFCs do (or will soon) exist. No, there are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has an IANA Considerations section that clearly explains what IANA should do. It asks for: 8 new Information Element numbers in the IPFIX IE Registry 3 new subregistries for: IE Data Types, IE Semantics, IE Units This all seems sensible and clear to me. Also, I have discussed it with Michelle Cotton (IANA); she agreed that now we have an IPFIX sub-registries entry in the IANA pages, there should be no problem adding three more sub-registries. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document has no parts written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. Working Group Summary This document started out as a section in the 'IPFIX File' draft; it was split out because it is useful in other contexts than files of IPFIX data. There was considerable mailing-list discussion on the best ways to do this, it took several months for all the issues to be resolved. Discussion ended late in June 08. The final version of this draft (July 08) resolved issues raised in discussion. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Paul Aitken and Gerhard Muenz; their reviews prompted discussion on the list. It has also been reviewed by the WG chairs. It describes a set of new IPFIX Information Elements, but does not make any changes to the IPFIX protocol. --------------060007080305080701090800 Content-Type: text/plain; name="file-format.writeup" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file-format.writeup" Document: draft-ietf-ipfix-file-03.txt Title: Specification of the IPFIX File Format Editors: B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Intended status: Standards Track As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particulaownward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split. No, now that psamp-info is in RFC EDitor queue, all the normative reference RFCs do (or will soon) exist. No, there are no downward references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has an IANA Considerations section that clearly explains what IANA should do. It asks for: 8 new Information Element numbers in the IPFIX IE Registry 3 new subregistries for: IE Data Types, IE Semantics, IE Units This all seems sensible and clear to me. Also, I have discussed it with Michelle Cotton (IANA); she agreed that now we have an IPFIX sub-registries entry in the IANA pages, there should be no problem adding three more sub-registries. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document has no parts written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes an extension to IPFIX to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise- specific Information Elements, facilitating interoperability and reusability among a wide variety of applications and tools. Working Group Summary This document started out as a section in the 'IPFIX File' draft; it was split out because it is useful in other contexts than files of IPFIX data. There was considerable mailing-list discussion on the best ways to do this, it took several months for all the issues to be resolved. Discussion ended late in June 08. The final version of this draft (July 08) resolved issues raised in discussion. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Paul Aitken and Gerhard Muenz; their reviews prompted discussion on the list. It has also been reviewed by the WG chairs. It describes a set of new IPFIX Information Elements, but does not make any changes to the IPFIX protocol. --------------060007080305080701090800 Content-Type: text/plain; name="file-format.writeup" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file-format.writeup" Document: draft-ietf-ipfix-file-03.txt Title: Specification of the IPFIX File Format Editors: B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Intended status: Standards Track As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated September 17, 2008. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular,r, does he or she believe this version is ready for forwarding to the IESG for publication? Nevil Brownlee. I have reviewed this draft, I believe it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This is version 3 of the draft. It has had extensive review by the WG members, and by others from the PSAMP WG. These reviews seem sufficiently thorough to me. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The draft is concerned only with specifying a way to store IPFIX Information in files so as to preserve it for later use, e.g. for analysis by application programs, for testing IPFIX colletcors, etc. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns for this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong consensus within the IPFIX Working Group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? idnits 2.10.02 says a. Change boilerplate to RFC 4748-style 16 Dec 08 is the 'required from' date b. Possible downref to ' IPFIX Exporting Types' draft This draft is now in RFC Editor queue b. Exporting Types is Standards Track, no problem. a. could be fixed in RFC Editor 48hr The draft is IPFIX-centric, it needs no other formal checks. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split. No, the only dangling reference is to the IPFIX Exporting Types draft; I'm submitting that together with this one. No, there are no downward references. (1.i) Has the Docu does he or she believe this version is ready for forwarding to the IESG for publication? Nevil Brownlee. I have reviewed this draft, I believe it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This is version 3 of the draft. It has had extensive review by the WG members, and by others from the PSAMP WG. These reviews seem sufficiently thorough to me. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The draft is concerned only with specifying a way to store IPFIX Information in files so as to preserve it for later use, e.g. for analysis by application programs, for testing IPFIX colletcors, etc. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns for this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This document has strong consensus within the IPFIX Working Group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? idnits 2.10.02 says a. Change boilerplate to RFC 4748-style 16 Dec 08 is the 'required from' date b. Possible downref to ' IPFIX Exporting Types' draft This draft is now in RFC Editor queue b. Exporting Types is Standards Track, no problem. a. could be fixed in RFC Editor 48hr The draft is IPFIX-centric, it needs no other formal checks. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split. No, the only dangling reference is to the IPFIX Exporting Types draft; I'm submitting that together with this one. No, there are no downward references. (1.i) Has the Documement Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has an IANA Considerations section that clearly explains what IANA should do. It asks for 16 new Information Element numbers in the IPFIX IE Registry. Now that the IFIX IE Registry is in production, this is a simple addition to it. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document has no parts written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. Working Group Summary Work started on this document in 2006, and has gone through several revisions in response to mailing list discussion. Originally it included the material about 'exporting type information,' but the WG split it out into a seperate RFC to make it more easily accessible for other uses. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Benoit Claise, Paul Aitken, Andrew Johnson, and Gerhard Muenz, as well as by the WG chairs. It specifies a file format for IPFIX data, making the point that this is simply another data transport for IPFIX. It does not make any changes to the IPFIX protocol. --------------060007080305080701090800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------060007080305080701090800-- nt Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The document has an IANA Considerations section that clearly explains what IANA should do. It asks for 16 new Information Element numbers in the IPFIX IE Registry. Now that the IFIX IE Registry is in production, this is a simple addition to it. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document has no parts written in a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a file format for the storage of flow data based upon the IPFIX Protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. Working Group Summary Work started on this document in 2006, and has gone through several revisions in response to mailing list discussion. Originally it included the material about 'exporting type information,' but the WG split it out into a seperate RFC to make it more easily accessible for other uses. The WG has reached a clear consensus on this draft. Document Quality This document has been reviwed by Benoit Claise, Paul Aitken, Andrew Johnson, and Gerhard Muenz, as well as by the WG chairs. It specifies a file format for IPFIX data, making the point that this is simply another data transport for IPFIX. It does not make any changes to the IPFIX protocol. --------------060007080305080701090800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------060007080305080701090800-- From ipfix-bounces@ietf.org Wed Nov 19 15:22:34 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F083A68AF; Wed, 19 Nov 2008 15:22:34 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F793A68AF for ; Wed, 19 Nov 2008 15:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6XfBudpXoY7 for ; Wed, 19 Nov 2008 15:22:33 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7FD6D3A6895 for ; Wed, 19 Nov 2008 15:22:32 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAJNMRVv006307; Thu, 20 Nov 2008 08:22:28 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 08:22:31 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: References: <4923D59E.7010209@informatik.uni-erlangen.de> Message-Id: <20081120075747.8B40.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 08:22:30 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Brian and Cristoph, Thank you for your suggestion. Please see in-line below. On Wed, 19 Nov 2008 10:38:18 -0600 Brian Trammell wrote: > Cristoph, all: > > In short, yes. In more detail, inline, below. > > On Nov 19, 2008, at 3:00 AM, Christoph Sommer wrote: > > > I propose the following two definitions: > > > > * Intermediate Process: > > a black box that processes Flow Records, i.e. that takes > > Flow Records as its input and has Flow Records as its output. > > Crucial here is "Flow Records", as in the same output of a Metering > Process, not necessarily IPFIX-encoded, as this allows the V5->IPFIX > and V9->IPFIX mediators. That make sense. And also it needs Packet Reports. > > > > > * IPFIX Mediator: > > a device that can host zero or more Intermediate Processes > > along with other Processes defined in IPFIX. > > Yep. I presume a mediator with zero intermediates would be used for > low-tech NAT traversal, transport protocol isolation, or transport > protocol/security layer translation? > Yes. > > I think these two definitions can be used to describe all > > currently-thought-of IPFIX Mediators by using zero or more > > Intermediate > > Processes (IMPs), like so: > > > > * IPFIX Proxy: > > Collector---Exporter > > > > * IPFIX Concentrator: > > Collector---"IMP Aggregator"---Exporter > > > > * IPFIX Distributor:From ipfix-bounces@ietf.org Wed Nov 19 15:22:34 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F083A68AF; Wed, 19 Nov 2008 15:22:34 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F793A68AF for ; Wed, 19 Nov 2008 15:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6XfBudpXoY7 for ; Wed, 19 Nov 2008 15:22:33 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7FD6D3A6895 for ; Wed, 19 Nov 2008 15:22:32 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAJNMRVv006307; Thu, 20 Nov 2008 08:22:28 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 08:22:31 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: References: <4923D59E.7010209@informatik.uni-erlangen.de> Message-Id: <20081120075747.8B40.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 08:22:30 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition (was: Mediator Problem Statement: Review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Brian and Cristoph, Thank you for your suggestion. Please see in-line below. On Wed, 19 Nov 2008 10:38:18 -0600 Brian Trammell wrote: > Cristoph, all: > > In short, yes. In more detail, inline, below. > > On Nov 19, 2008, at 3:00 AM, Christoph Sommer wrote: > > > I propose the following two definitions: > > > > * Intermediate Process: > > a black box that processes Flow Records, i.e. that takes > > Flow Records as its input and has Flow Records as its output. > > Crucial here is "Flow Records", as in the same output of a Metering > Process, not necessarily IPFIX-encoded, as this allows the V5->IPFIX > and V9->IPFIX mediators. That make sense. And also it needs Packet Reports. > > > > > * IPFIX Mediator: > > a device that can host zero or more Intermediate Processes > > along with other Processes defined in IPFIX. > > Yep. I presume a mediator with zero intermediates would be used for > low-tech NAT traversal, transport protocol isolation, or transport > protocol/security layer translation? > Yes. > > I think these two definitions can be used to describe all > > currently-thought-of IPFIX Mediators by using zero or more > > Intermediate > > Processes (IMPs), like so: > > > > * IPFIX Proxy: > > Collector---Exporter > > > > * IPFIX Concentrator: > > Collector---"IMP Aggregator"---Exporter > > > > * IPFIX Distributor: > > Collector---"IMP Distributor"---Exporter(s) > > > > * IPFIX Masquerading Proxy: > > Collector---"IMP Masquerade"---Exporter > > (btw, I like the "IMP" notation, because "IP" would be confusing. How > about "ImP" though, as it's two words, not three?) > > Of course we should note that you can chain intermediate processes > arbitrarily: > > IPFIX redistributing anonymizing aggregator: > Collector --- "ImP Aggregator" --- "ImP Anonymizer" --- "ImP > Distributor" --- Exporter(s) > Yes. And also, I can image the chain of functions just like composite selectors in PSAMP. In both way, we can consider chain. +-------------------ImP---------------------+ Collector --- |"Aggregator" - "Anonymizer" - "Distributor"| - Exporter(s) +-------------------------------------------+ Or, should we select either way? Regards, Atsushi KOBAYASHI > > I would like to hear as many comments/suggestions as possible, so we > > can > > arrive at a clear definition of what an IPFIX Mediator is and what an > > Intermediate Process can do! > > > > > > Regards, > > > > Christoph > > > > -- > > Christoph Sommer > > Computer Networks and Communication Systems > > University of Erlangen-Nuremberg, Germany > > Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 > > http://www7.informatik.uni-erlangen.de/~sommer/ > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix > > Collector---"IMP Distributor"---Exporter(s) > > > > * IPFIX Masquerading Proxy: > > Collector---"IMP Masquerade"---Exporter > > (btw, I like the "IMP" notation, because "IP" would be confusing. How > about "ImP" though, as it's two words, not three?) > > Of course we should note that you can chain intermediate processes > arbitrarily: > > IPFIX redistributing anonymizing aggregator: > Collector --- "ImP Aggregator" --- "ImP Anonymizer" --- "ImP > Distributor" --- Exporter(s) > Yes. And also, I can image the chain of functions just like composite selectors in PSAMP. In both way, we can consider chain. +-------------------ImP---------------------+ Collector --- |"Aggregator" - "Anonymizer" - "Distributor"| - Exporter(s) +-------------------------------------------+ Or, should we select either way? Regards, Atsushi KOBAYASHI > > I would like to hear as many comments/suggestions as possible, so we > > can > > arrive at a clear definition of what an IPFIX Mediator is and what an > > Intermediate Process can do! > > > > > > Regards, > > > > Christoph > > > > -- > > Christoph Sommer > > Computer Networks and Communication Systems > > University of Erlangen-Nuremberg, Germany > > Phone: +49 9131 85-27993 / Fax: +49 9131 85-27409 > > http://www7.informatik.uni-erlangen.de/~sommer/ > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 02:52:56 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B053A6A17; Thu, 20 Nov 2008 02:52:56 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6F43A6A17 for ; Thu, 20 Nov 2008 02:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef-EOStlL95y for ; Thu, 20 Nov 2008 02:52:53 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5FA243A69EF for ; Thu, 20 Nov 2008 02:52:51 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKAqckb010228; Thu, 20 Nov 2008 19:52:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 19:52:45 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492468F1.8050606@net.in.tum.de> References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> Message-Id: <20081120190050.8B43.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 19:52:44 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Thank you for quick reply. On Wed, 19 Nov 2008 20:28:49 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > > Gerhard Muenz wrote: > >> For me, the purpose of the draft is not quite clear. Is it to justify > >> the need of IPFIX Mediators? Then, the focus should be more on > >> monitoring situations that cannot be adequately handled without this > >> intermediate box between exporters and collectors. > > > > This draft covers the possible examples related to Mediation, > > and some problems that IPFIX mediator will face in future. > > Hm. In my opinion, "problem statement" refers to the problems we want to > solve with Mediation, not to problems we will have because of Mediation. > Hmmmm, I see. > > For me, some of applicable examples shows vital function, such as "IPFIX > > Export Across Domains" or "Interoperability between Legacy Protocols and > > IPFIX". > > I think that it is better to gather other applicable examples than > > focusing on vital functions in order to show the effectiveness of > > mediator. > > > > So, I am wondering if some applicable examples should be removed or if > > other more vital examples should be added. What do you think? > > I think it is ok to discuss what is possible without Mediation and to > show the limits of "state-of-the-art" IPFIX. > So, you could > - present a problem, > - show how the problem could be solved without mediation (if possible), > - argue why this solution is not optimal, and > - present how mediation enables a better solution. > That make sense. > >> If functionalities like configurable flow keys, flow selection, > >> anonymization are realized on an IPFIX exporter directly, they can be > >> considered as part of the Metering Process. So, there is no mediation > >> involved. > >> > > > > Certainly, some of mediation function can be considered as part of > > Metering Process. But, maintaining Flow Records is main task of Metering > > Process. > > > > Other functions, such as anonymization or flow selection, are not > > limited to be included in Metering Process. For example, I can think > > that the general Metering Process in interface module can create Flow > > Records, and then Mediation in main cpu module can anonymize them. > > > > Therefore, locating "mediation" in any devices can be utilized. > > Ok. > > > Please see following text regarding other comments. > > See some comments below. > > Regards, > Gerhard > > > >>> network monitoring usages. The sharing of flow-based information > >>> among orthogonal monitoring applications raises open issues in terms > >> not sure what you mean by "orthogonal" > >> > > > > The requirement of several applications in same network could be > > orthogonal as following. > > - Granularity of Flow Records: coarse-grained or fine-grained. > > - Time of period for storage: long-term or short-term. > > - Traceability: anonymization or not. > > > > These situation could not be compatible without mediation. > > I will consider more about this sentence. > > Ok. So the requirements are orthogonal, not the applications themselves. > Maybe you find a better word for "orthogonal". > Ok. I will try. > >>> 1. Introduction > >>> > >>> > >>> While the IPFIX requirements defined in [RFC3917] mention an > >>> intermediate function, such as an IPFIX Proxy or an Concentrator, > >> "...mention intermediate functions, such as IPFIX proxies and IPFIX > >> concentrators [not sure if these terms should start with capital > >> letters],..." > >> > > > > Do you mean the capital letters are not allowed to be used before terminology > > section? > > Forget about my comment. It's just that Concentrator has not yet been a > fixed term in any IPFIX document. But as you introduce it in the > terminology section, it's ok. > > >>> 2. Terminology and Definition > >>> > >>> > >>> The terms in this section are in line with those in the IPFIX > >>> specification document [RFC5101] and the PSAMP specification document > >>> [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > >> What do you mean by "inline"? > >> If you reuse terms from RFC5101, then you do not have to repeat them > >> here. Only additional terms should appear in this section. Otherwise it > >> is not clear which terms are new. > >> > > > > At first, I added terms from RFC5101 to make it easy-to-understand for > > first IPFIX reader. But, it does not clear whether there is a difference > > between original term, even if same. > > > > I will improve the following description. > > > > Flow Key [RFC5101] > > > > Flow Record [RFC5101] > > > > Observation Point [RFC5101] > > > > Exporter [RFC5101] > > > > Collector [RFC5101] > > The question if we should repeat terms in every terminology sections > arises with every new draft ;) > > IMO, it is necessary to put the readers attention to the new terms, > maybe by moving them in on subsection "new terms". Old terms may be > repeated in another subsection. Separating subsection seems to be better solution. > Be careful with redefining terms from a standard track document! > I see. > >>> IPFIX Mediation can be included in any devices, such as routers, > >>> switches, NMS(Network Management Systems), or be deployed in > >>> stand-alone devices. > >> I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX > >> Mediators. If performed on the original exporter, we already do have the > >> Metering Process which can do all these things. > >> > > > > I can image that IPFIX Mediation function is located between Metering > > and Exporting Process. > > Ok. > > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator contains one or more functions defined in IPFIX > >> "one or more IPFIX Mediation functions" > >> > >>> Mediation. The IPFIX Mediator can be a stand-alone or a virtual > >>> device. It also contains one or more Collecting Processes and one > >> What do you mean by "virtual"? > >> > > > > If IPFIX Mediator and Exporter are located in same device, IPFIX > > Mediator is virtual device rather than stand-alone. > > I would not rather restrict possible implementations. > > Two possibilities: > - remove the sentence > - explain a little bit further what you mean by "virtual" > Ok. I will explain more about it. > >>> IPFIX Proxy > >>> > >>> An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > >>> from Original Exporter, and sends IPFIX Messages to one or more > >> It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX > >> Mediator? > > > > Yes. I would not rather restrict it. I need to improve them. > > > >> Sending to multiple Collectors requires "replication" of IPFIX Messages, > >> which implies that the included records are replicated as well. > > > > Yes. > >> You mention "replication" in the case of IPFIX Distributor below. Maybe > >> you want to mention it here as well? > > > > No. As you mentioned below, I mean IPFIX Distributor replicates Records. > > Ok. You still could mention that the IPFIX Proxy duplicates Messages if > they are sent to multiple Collectors. > > >> What is the difference between IPFIX Proxy and IPFIX Distributor? > >> Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX > >> Distributor handles individual records? > >> > > > > Yes. > > Maybe you can clarify this in the text. > > >>> IPFIX Masquerading Proxy > >>> > >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > >>> a part of data of input Flow Records/Packet Reports according to > >>> configured policies. It can thus, for example, hide the network > >>> topology information or customers' IP addresses. > >> Note: If you call this a "proxy", then my above distinction between > >> IPFIX Proxy and IPFIX Distributor does not work. > > > > Is it strange that IPFIX Masquerading Proxy handles Records, > > although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handles > > Records? > > At least, it's a bit confusing. > > Alternatively, you could forget about the "IPFIX Distributor" and call > it "IPFIX Proxy" as well because there is no real difference between > IPFIX Proxy and IPFIX Distributor. > > If a Proxy is used to translate Netflow into IPFIX, it also has to > change the messages and maybe the Records. Hmm, you means that it seems to be no difference whichever they replicate, if you see them as black box. Certainly, Yes. But, first of all, I have forgot to write the role of each box. IPFIX Proxy has the role doing like Original Exporter from viewpoint of Collector. Therefore, Collector recognize that source IP address of IPFIX Proxy is that of Original Exporter. On the other hand, IPFIX Distributor does not has the role. IPFIX Distributor can send Original Exporter information in some way. It depends on the configuration policy. Does it make sense? > > >> 3.2. Data Retention > >>> > >>> > >>> Data retention refers to the storage of traffic data by service > >>> providers and commercial organizations. According to European > >>> Commission directives, operators are required to retain both IP and > >>> voice traffic data, in wired and wireless networks, generated by end > >>> users while using a service provider's services. The goal of data > >>> retention is to ensure that call detail records and Flow Records are > >>> available for the purpose oFrom ipfix-bounces@ietf.org Thu Nov 20 02:52:56 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B053A6A17; Thu, 20 Nov 2008 02:52:56 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C6F43A6A17 for ; Thu, 20 Nov 2008 02:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ef-EOStlL95y for ; Thu, 20 Nov 2008 02:52:53 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5FA243A69EF for ; Thu, 20 Nov 2008 02:52:51 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKAqckb010228; Thu, 20 Nov 2008 19:52:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 19:52:45 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492468F1.8050606@net.in.tum.de> References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> Message-Id: <20081120190050.8B43.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 19:52:44 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Thank you for quick reply. On Wed, 19 Nov 2008 20:28:49 +0100 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > > Gerhard Muenz wrote: > >> For me, the purpose of the draft is not quite clear. Is it to justify > >> the need of IPFIX Mediators? Then, the focus should be more on > >> monitoring situations that cannot be adequately handled without this > >> intermediate box between exporters and collectors. > > > > This draft covers the possible examples related to Mediation, > > and some problems that IPFIX mediator will face in future. > > Hm. In my opinion, "problem statement" refers to the problems we want to > solve with Mediation, not to problems we will have because of Mediation. > Hmmmm, I see. > > For me, some of applicable examples shows vital function, such as "IPFIX > > Export Across Domains" or "Interoperability between Legacy Protocols and > > IPFIX". > > I think that it is better to gather other applicable examples than > > focusing on vital functions in order to show the effectiveness of > > mediator. > > > > So, I am wondering if some applicable examples should be removed or if > > other more vital examples should be added. What do you think? > > I think it is ok to discuss what is possible without Mediation and to > show the limits of "state-of-the-art" IPFIX. > So, you could > - present a problem, > - show how the problem could be solved without mediation (if possible), > - argue why this solution is not optimal, and > - present how mediation enables a better solution. > That make sense. > >> If functionalities like configurable flow keys, flow selection, > >> anonymization are realized on an IPFIX exporter directly, they can be > >> considered as part of the Metering Process. So, there is no mediation > >> involved. > >> > > > > Certainly, some of mediation function can be considered as part of > > Metering Process. But, maintaining Flow Records is main task of Metering > > Process. > > > > Other functions, such as anonymization or flow selection, are not > > limited to be included in Metering Process. For example, I can think > > that the general Metering Process in interface module can create Flow > > Records, and then Mediation in main cpu module can anonymize them. > > > > Therefore, locating "mediation" in any devices can be utilized. > > Ok. > > > Please see following text regarding other comments. > > See some comments below. > > Regards, > Gerhard > > > >>> network monitoring usages. The sharing of flow-based information > >>> among orthogonal monitoring applications raises open issues in terms > >> not sure what you mean by "orthogonal" > >> > > > > The requirement of several applications in same network could be > > orthogonal as following. > > - Granularity of Flow Records: coarse-grained or fine-grained. > > - Time of period for storage: long-term or short-term. > > - Traceability: anonymization or not. > > > > These situation could not be compatible without mediation. > > I will consider more about this sentence. > > Ok. So the requirements are orthogonal, not the applications themselves. > Maybe you find a better word for "orthogonal". > Ok. I will try. > >>> 1. Introduction > >>> > >>> > >>> While the IPFIX requirements defined in [RFC3917] mention an > >>> intermediate function, such as an IPFIX Proxy or an Concentrator, > >> "...mention intermediate functions, such as IPFIX proxies and IPFIX > >> concentrators [not sure if these terms should start with capital > >> letters],..." > >> > > > > Do you mean the capital letters are not allowed to be used before terminology > > section? > > Forget about my comment. It's just that Concentrator has not yet been a > fixed term in any IPFIX document. But as you introduce it in the > terminology section, it's ok. > > >>> 2. Terminology and Definition > >>> > >>> > >>> The terms in this section are in line with those in the IPFIX > >>> specification document [RFC5101] and the PSAMP specification document > >>> [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > >> What do you mean by "inline"? > >> If you reuse terms from RFC5101, then you do not have to repeat them > >> here. Only additional terms should appear in this section. Otherwise it > >> is not clear which terms are new. > >> > > > > At first, I added terms from RFC5101 to make it easy-to-understand for > > first IPFIX reader. But, it does not clear whether there is a difference > > between original term, even if same. > > > > I will improve the following description. > > > > Flow Key [RFC5101] > > > > Flow Record [RFC5101] > > > > Observation Point [RFC5101] > > > > Exporter [RFC5101] > > > > Collector [RFC5101] > > The question if we should repeat terms in every terminology sections > arises with every new draft ;) > > IMO, it is necessary to put the readers attention to the new terms, > maybe by moving them in on subsection "new terms". Old terms may be > repeated in another subsection. Separating subsection seems to be better solution. > Be careful with redefining terms from a standard track document! > I see. > >>> IPFIX Mediation can be included in any devices, such as routers, > >>> switches, NMS(Network Management Systems), or be deployed in > >>> stand-alone devices. > >> I'm not sure. I would rather restrict IPFIX Mediation functions to IPFIX > >> Mediators. If performed on the original exporter, we already do have the > >> Metering Process which can do all these things. > >> > > > > I can image that IPFIX Mediation function is located between Metering > > and Exporting Process. > > Ok. > > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator contains one or more functions defined in IPFIX > >> "one or more IPFIX Mediation functions" > >> > >>> Mediation. The IPFIX Mediator can be a stand-alone or a virtual > >>> device. It also contains one or more Collecting Processes and one > >> What do you mean by "virtual"? > >> > > > > If IPFIX Mediator and Exporter are located in same device, IPFIX > > Mediator is virtual device rather than stand-alone. > > I would not rather restrict possible implementations. > > Two possibilities: > - remove the sentence > - explain a little bit further what you mean by "virtual" > Ok. I will explain more about it. > >>> IPFIX Proxy > >>> > >>> An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > >>> from Original Exporter, and sends IPFIX Messages to one or more > >> It is possible that an IPFIX Proxy receives IPFIX Messages from an IPFIX > >> Mediator? > > > > Yes. I would not rather restrict it. I need to improve them. > > > >> Sending to multiple Collectors requires "replication" of IPFIX Messages, > >> which implies that the included records are replicated as well. > > > > Yes. > >> You mention "replication" in the case of IPFIX Distributor below. Maybe > >> you want to mention it here as well? > > > > No. As you mentioned below, I mean IPFIX Distributor replicates Records. > > Ok. You still could mention that the IPFIX Proxy duplicates Messages if > they are sent to multiple Collectors. > > >> What is the difference between IPFIX Proxy and IPFIX Distributor? > >> Is it that an IPFIX Proxy handles entire IPFIX Messages while an IPFIX > >> Distributor handles individual records? > >> > > > > Yes. > > Maybe you can clarify this in the text. > > >>> IPFIX Masquerading Proxy > >>> > >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > >>> a part of data of input Flow Records/Packet Reports according to > >>> configured policies. It can thus, for example, hide the network > >>> topology information or customers' IP addresses. > >> Note: If you call this a "proxy", then my above distinction between > >> IPFIX Proxy and IPFIX Distributor does not work. > > > > Is it strange that IPFIX Masquerading Proxy handles Records, > > although IPFIX Proxy handles IPFIX Message and IPFIX Distributor handles > > Records? > > At least, it's a bit confusing. > > Alternatively, you could forget about the "IPFIX Distributor" and call > it "IPFIX Proxy" as well because there is no real difference between > IPFIX Proxy and IPFIX Distributor. > > If a Proxy is used to translate Netflow into IPFIX, it also has to > change the messages and maybe the Records. Hmm, you means that it seems to be no difference whichever they replicate, if you see them as black box. Certainly, Yes. But, first of all, I have forgot to write the role of each box. IPFIX Proxy has the role doing like Original Exporter from viewpoint of Collector. Therefore, Collector recognize that source IP address of IPFIX Proxy is that of Original Exporter. On the other hand, IPFIX Distributor does not has the role. IPFIX Distributor can send Original Exporter information in some way. It depends on the configuration policy. Does it make sense? > > >> 3.2. Data Retention > >>> > >>> > >>> Data retention refers to the storage of traffic data by service > >>> providers and commercial organizations. According to European > >>> Commission directives, operators are required to retain both IP and > >>> voice traffic data, in wired and wireless networks, generated by end > >>> users while using a service provider's services. The goal of data > >>> retention is to ensure that call detail records and Flow Records are > >>> available for the purpose of detection, investigation, and > >>> prosecution of serious crimes, if necessary. The European Commission > >>> directives define the following data retention services: > >>> > >>> o Fixed telephony (includes fixed voice, voicemail, and conference > >>> and data calls) > >>> > >>> o Mobile telephony (includes mobile voice, voicemail, conference and > >>> data calls, SMS, and MMS) > >>> > >>> o Internet telephony (includes every multimedia session associated > >>> with IP multimedia services) > >>> > >>> o Internet e-mail > >>> > >>> o Internet access > >>> > >>> By monitoring Flow Records, IPFIX can fulfill these requirements of > >>> Internet access services. > >> Ok, but where is the link to IPFIX Mediation? > >> > > > > It is possible examples. IPFIX Mediation with storage allow collection > > system to become huge storage to suit data retention. > > Ok. You might add a sentence saying that mediation (e.g. IPFIX > distributor) is needed to handle the flow data required by these > regulations. > Ok. Thank you. > >>> Metering Process allows operators to specify their own set of Flow > >>> Keys and extra Information Elements in the Template Record. > >>> Specifically, Original Exporters classify the Flow Records by their > >>> contents, and then aggregate them with appropriate Flow keys based on > >> You assume one specific implementation where the Metering Process first > >> produces IP-quintuple Flows which are then aggregated. However, it is > >> also possible to directly generate Flows with Flow Key fields differing > >> from the usual IP-quintuple. In this case, it is not an IPFIX Mediation > >> function but just a Metering Process. Also, I would not call this case > >> flow "aggregation". > >> > > > > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And > > then, Metering Process can create aggregated Flow Records without > > Mediation. > > > > But, in some case, Metering Process in port module creates IP-quintuple > > Flow and then mediation function in main cpu creates aggregated Flow. > > Ok. So you might add that this solution is useful in the case where > unconfigurable MPs creating IP-quintuple flow records exist. > Thank you. > >>> another for capacity planning, and so on. The content and > >>> granularity of the Flow can satisfy the requirements of each > >>> Collector with a specific application. > >>> > >>> On one hand, this optimizes the Metering Process, because only Flows > >>> of interest are looked at. On the other hand, it optimizes the > >>> Exporting Process, because only the information of interest is > >>> exported. Finally, this reduces load of the Collecting Process as > >>> less Flow Records are handled, and Flow Record filtering and > >>> aggregating are required. > >> Ok. So this subsection proposed a solution that works without IPFIX > >> Mediation. > >> > > > > Yes... > > > > I write down several solution against the large traffic volume in the > > sections regardless of whether using Mediation or not. > > Does it confuse you? > > You could distinguish visibly between solutions not requiring Mediation > and solutions that work with Mediation only. > I will try it. > >>> these identifiers and the received Transport Session Information, the > >>> Mediators would, for example, relay wrong values for the scope fields > >>> of the Option Template and for a "Template Withdraw Message". In > >> You assume that the Template ID is in the Option's scope. That does not > >> have to be the case. > >> > > > > Generally, Template ID is used as the Option's scope. > > Hm, no. Have a look at: > http://tools.ietf.org/html/rfc5101#section-4 > Only the Flow Keys Option contains the Temlate ID. > Certainly. Yes. I will try to improve it. > > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix f detection, investigation, and > >>> prosecution of serious crimes, if necessary. The European Commission > >>> directives define the following data retention services: > >>> > >>> o Fixed telephony (includes fixed voice, voicemail, and conference > >>> and data calls) > >>> > >>> o Mobile telephony (includes mobile voice, voicemail, conference and > >>> data calls, SMS, and MMS) > >>> > >>> o Internet telephony (includes every multimedia session associated > >>> with IP multimedia services) > >>> > >>> o Internet e-mail > >>> > >>> o Internet access > >>> > >>> By monitoring Flow Records, IPFIX can fulfill these requirements of > >>> Internet access services. > >> Ok, but where is the link to IPFIX Mediation? > >> > > > > It is possible examples. IPFIX Mediation with storage allow collection > > system to become huge storage to suit data retention. > > Ok. You might add a sentence saying that mediation (e.g. IPFIX > distributor) is needed to handle the flow data required by these > regulations. > Ok. Thank you. > >>> Metering Process allows operators to specify their own set of Flow > >>> Keys and extra Information Elements in the Template Record. > >>> Specifically, Original Exporters classify the Flow Records by their > >>> contents, and then aggregate them with appropriate Flow keys based on > >> You assume one specific implementation where the Metering Process first > >> produces IP-quintuple Flows which are then aggregated. However, it is > >> also possible to directly generate Flows with Flow Key fields differing > >> from the usual IP-quintuple. In this case, it is not an IPFIX Mediation > >> function but just a Metering Process. Also, I would not call this case > >> flow "aggregation". > >> > > > > Yes. The term Flow covers IP-quintuple Flow and aggregated Flow. And > > then, Metering Process can create aggregated Flow Records without > > Mediation. > > > > But, in some case, Metering Process in port module creates IP-quintuple > > Flow and then mediation function in main cpu creates aggregated Flow. > > Ok. So you might add that this solution is useful in the case where > unconfigurable MPs creating IP-quintuple flow records exist. > Thank you. > >>> another for capacity planning, and so on. The content and > >>> granularity of the Flow can satisfy the requirements of each > >>> Collector with a specific application. > >>> > >>> On one hand, this optimizes the Metering Process, because only Flows > >>> of interest are looked at. On the other hand, it optimizes the > >>> Exporting Process, because only the information of interest is > >>> exported. Finally, this reduces load of the Collecting Process as > >>> less Flow Records are handled, and Flow Record filtering and > >>> aggregating are required. > >> Ok. So this subsection proposed a solution that works without IPFIX > >> Mediation. > >> > > > > Yes... > > > > I write down several solution against the large traffic volume in the > > sections regardless of whether using Mediation or not. > > Does it confuse you? > > You could distinguish visibly between solutions not requiring Mediation > and solutions that work with Mediation only. > I will try it. > >>> these identifiers and the received Transport Session Information, the > >>> Mediators would, for example, relay wrong values for the scope fields > >>> of the Option Template and for a "Template Withdraw Message". In > >> You assume that the Template ID is in the Option's scope. That does not > >> have to be the case. > >> > > > > Generally, Template ID is used as the Option's scope. > > Hm, no. Have a look at: > http://tools.ietf.org/html/rfc5101#section-4 > Only the Flow Keys Option contains the Temlate ID. > Certainly. Yes. I will try to improve it. > > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 03:43:15 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25903A6A2F; Thu, 20 Nov 2008 03:43:14 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997D03A6A2D for ; Thu, 20 Nov 2008 03:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l3evQfDBRGX for ; Thu, 20 Nov 2008 03:43:12 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id C802E3A63D2 for ; Thu, 20 Nov 2008 03:43:11 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id mAKBh98n000981; Thu, 20 Nov 2008 20:43:10 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E45EA6602; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DC5066600; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8jL015731; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8GN015728; Thu, 20 Nov 2008 20:43:08 +0900 (JST) Received: from [129.60.149.158] ([129.60.149.158]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8ms016428; Thu, 20 Nov 2008 20:43:08 +0900 (JST) Message-Id: <6CD50A39-4463-4745-9023-8DCBE2E25782@lab.ntt.co.jp> From: Nishida Haruhiko To: Atsushi Kobayashi In-Reply-To: <20081120190050.8B43.17391CF2@nttv6.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 20:44:10 +0900 References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> <20081120190050.8B43.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.929.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Atsushi, Gerhard, On 2008/11/20, at 19:52, Atsushi Kobayashi wrote: >>> Gerhard Muenz wrote: >>>> For me, the purpose of the draft is not quite clear. Is it to justify >>>> the need of IPFIX Mediators? Then, the focus should be more on >>>> monitoring situations that cannot be adequately handled without this >>>> intermediate box between exporters and collectors. >>> >>> This draft covers the possible examples related to Mediation, >>> and some problems that IPFIX mediator will face in future. >> >> Hm. In my opinion, "problem statement" refers to the problems we want to >> solve with Mediation, not to problems we will have because of Mediation. >> > > Hmmmm, I see. As Gerhard stated, current problem statement has two faces; how Mediator will be nice, and What we should re-consider on current IPFIX specifications if we introduce the Mediator. What in my mind was, problem statement is to evaluate a topic (Mediator) whether it is worth to discuss in WG. This is the reason why Atsushi and me decided to put the later part in the problem statement. Other than that, I don't have strong opinion whether we should/should not include the later part in the problem statement, because we seem already have agreed to work on Mediator. -- Haru Nishida _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 03:43:15 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25903A6A2F; Thu, 20 Nov 2008 03:43:14 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997D03A6A2D for ; Thu, 20 Nov 2008 03:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l3evQfDBRGX for ; Thu, 20 Nov 2008 03:43:12 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id C802E3A63D2 for ; Thu, 20 Nov 2008 03:43:11 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id mAKBh98n000981; Thu, 20 Nov 2008 20:43:10 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E45EA6602; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DC5066600; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8jL015731; Thu, 20 Nov 2008 20:43:09 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8GN015728; Thu, 20 Nov 2008 20:43:08 +0900 (JST) Received: from [129.60.149.158] ([129.60.149.158]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id mAKBh8ms016428; Thu, 20 Nov 2008 20:43:08 +0900 (JST) Message-Id: <6CD50A39-4463-4745-9023-8DCBE2E25782@lab.ntt.co.jp> From: Nishida Haruhiko To: Atsushi Kobayashi In-Reply-To: <20081120190050.8B43.17391CF2@nttv6.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 20:44:10 +0900 References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> <20081120190050.8B43.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.929.2) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Atsushi, Gerhard, On 2008/11/20, at 19:52, Atsushi Kobayashi wrote: >>> Gerhard Muenz wrote: >>>> For me, the purpose of the draft is not quite clear. Is it to justify >>>> the need of IPFIX Mediators? Then, the focus should be more on >>>> monitoring situations that cannot be adequately handled without this >>>> intermediate box between exporters and collectors. >>> >>> This draft covers the possible examples related to Mediation, >>> and some problems that IPFIX mediator will face in future. >> >> Hm. In my opinion, "problem statement" refers to the problems we want to >> solve with Mediation, not to problems we will have because of Mediation. >> > > Hmmmm, I see. As Gerhard stated, current problem statement has two faces; how Mediator will be nice, and What we should re-consider on current IPFIX specifications if we introduce the Mediator. What in my mind was, problem statement is to evaluate a topic (Mediator) whether it is worth to discuss in WG. This is the reason why Atsushi and me decided to put the later part in the problem statement. Other than that, I don't have strong opinion whether we should/should not include the later part in the problem statement, because we seem already have agreed to work on Mediator. -- Haru Nishida _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 04:43:47 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFFA3A688A; Thu, 20 Nov 2008 04:43:47 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914A93A688A for ; Thu, 20 Nov 2008 04:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVKbfSnEU8ws for ; Thu, 20 Nov 2008 04:43:45 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 860F13A6768 for ; Thu, 20 Nov 2008 04:43:45 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id A477247B3C; Thu, 20 Nov 2008 13:43:33 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 525A22A51; Thu, 20 Nov 2008 13:43:33 +0100 (CET) Message-ID: <49255B80.2020000@net.in.tum.de> Date: Thu, 20 Nov 2008 13:43:44 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> <20081120190050.8B43.17391CF2@nttv6.net> In-Reply-To: <20081120190050.8B43.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377411618==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0377411618== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803010005080704050804" This is a cryptographically signed message in MIME format. --------------ms050803010005080704050804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Regarding the difference between IPFIX Proxy and IPFIX Distributor, the following distinction could work: IPFIX Proxy relays incoming transport sessions to one or multiple Collectors. The protocols used at the input and the output may be different, which implies that messages, templates, or records might need to be reencoded. IPFIX Distributor distributes incoming IPFIX Data Records to one or multiple IPFIX Collectors. The decision to which IPFIX Collector a IPFIX Data Record is exported may depend on filters on certain field values or other properties derived from the IPFIX Data Record. So, IPFIX Distributors do not perform any protocol translation (IPFIX at input and output) while IPFIX Proxies do not filter. What do you think? Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network ArchitectuFrom ipfix-bounces@ietf.org Thu Nov 20 04:43:47 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBFFA3A688A; Thu, 20 Nov 2008 04:43:47 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914A93A688A for ; Thu, 20 Nov 2008 04:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVKbfSnEU8ws for ; Thu, 20 Nov 2008 04:43:45 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 860F13A6768 for ; Thu, 20 Nov 2008 04:43:45 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id A477247B3C; Thu, 20 Nov 2008 13:43:33 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 525A22A51; Thu, 20 Nov 2008 13:43:33 +0100 (CET) Message-ID: <49255B80.2020000@net.in.tum.de> Date: Thu, 20 Nov 2008 13:43:44 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081119003311.E5B7.17391CF2@nttv6.net> <492468F1.8050606@net.in.tum.de> <20081120190050.8B43.17391CF2@nttv6.net> In-Reply-To: <20081120190050.8B43.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377411618==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0377411618== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050803010005080704050804" This is a cryptographically signed message in MIME format. --------------ms050803010005080704050804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Regarding the difference between IPFIX Proxy and IPFIX Distributor, the following distinction could work: IPFIX Proxy relays incoming transport sessions to one or multiple Collectors. The protocols used at the input and the output may be different, which implies that messages, templates, or records might need to be reencoded. IPFIX Distributor distributes incoming IPFIX Data Records to one or multiple IPFIX Collectors. The decision to which IPFIX Collector a IPFIX Data Record is exported may depend on filters on certain field values or other properties derived from the IPFIX Data Record. So, IPFIX Distributors do not perform any protocol translation (IPFIX at input and output) while IPFIX Proxies do not filter. What do you think? Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architecres and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms050803010005080704050804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAtures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms050803010005080704050804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcQkFMQ8XDTA4MTEyMDEyNDM0NFowIwYJKoZIhvcNAQkEMRYEFHjPIW72Ah9+ w/IbrI+aZ2L7OFcIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBHXVc9jW7RKeOSXMzlWK8q3l9BaqhGLeytZT3yzzE5TS01GjsMxYwqhv1p 58nZujy5d09+Vkx4AhTnJs8WYBeMr1wvDPcNAQd2ZMTcGRQKtqKy2Dlol9HjhBdZe0oYWXNE ytyXX6lpSdJpKBg3RU/Mfya8Tjd4ZzBJl+AELHS0Mwk0AVgDC+NxVhIEEDqL7jUNfqZTrTJ/ HTpTaxxRN/Gp/atVI2hJ9Lr3FHZVZHxlkdIVkHvIbRthVTmgKzxqfs1ZiL8GarRfm/plGDwn QiJ0cNfx8dV7RufcXU/OzxKw7u1gywuSy1U/kS1w8GBr8S/1IqVf8rqXqwiLKRQ2Kz+0AAAA AAAA --------------ms050803010005080704050804-- --===============0377411618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0377411618==-- NAQkFMQ8XDTA4MTEyMDEyNDM0NFowIwYJKoZIhvcNAQkEMRYEFHjPIW72Ah9+ w/IbrI+aZ2L7OFcIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQBHXVc9jW7RKeOSXMzlWK8q3l9BaqhGLeytZT3yzzE5TS01GjsMxYwqhv1p 58nZujy5d09+Vkx4AhTnJs8WYBeMr1wvDPcNAQd2ZMTcGRQKtqKy2Dlol9HjhBdZe0oYWXNE ytyXX6lpSdJpKBg3RU/Mfya8Tjd4ZzBJl+AELHS0Mwk0AVgDC+NxVhIEEDqL7jUNfqZTrTJ/ HTpTaxxRN/Gp/atVI2hJ9Lr3FHZVZHxlkdIVkHvIbRthVTmgKzxqfs1ZiL8GarRfm/plGDwn QiJ0cNfx8dV7RufcXU/OzxKw7u1gywuSy1U/kS1w8GBr8S/1IqVf8rqXqwiLKRQ2Kz+0AAAA AAAA --------------ms050803010005080704050804-- --===============0377411618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0377411618==-- From ipfix-bounces@ietf.org Thu Nov 20 05:22:33 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18B3A68CD; Thu, 20 Nov 2008 05:22:33 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A053A68CD for ; Thu, 20 Nov 2008 05:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeuIzmzH0L6J for ; Thu, 20 Nov 2008 05:22:31 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 216FA3A6837 for ; Thu, 20 Nov 2008 05:22:30 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKDMRYr011005; Thu, 20 Nov 2008 22:22:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 22:22:31 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <49255B80.2020000@net.in.tum.de> References: <20081120190050.8B43.17391CF2@nttv6.net> <49255B80.2020000@net.in.tum.de> Message-Id: <20081120221734.0A4C.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 22:22:28 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661099586==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0661099586== Content-Type: text/plain; charset="Shift_JIS" Content-Transfer-Encoding: quoted-printable Hi Gerhard, On Thu, 20 Nov 2008 13:43:44 +0100 Gerhard Muenz wrote: >=20 > Hi Atsushi, >=20 > Regarding the difference between IPFIX Proxy and IPFIX Distributor, the > following distinction could work: >=20 > IPFIX Proxy relays incoming transport sessions to one or multiple > Collectors. The protocols used at the input and the output may be > different, which implies that messages, templates, or records might need > to be reencoded. >=20 > IPFIX Distributor distributes incoming IPFIX Data Records to one or > multiple IPFIX Collectors. The decision to which IPFIX Collector a IPFIX > Data Record is exported may depend on filters on certain field values or > other properties derived from the IPFIX Data Record. >=20 > So, IPFIX Distributors do not perform any protocol translation (IPFIX at > input and output) while IPFIX Proxies do not filter. >=20 > What do you think? That makes sense! I will use your text. Thank you. Regards, Atsushi Kobayashi >=20 > Regards, > Gerhard >=20 > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 >=20 --=20 Atsushi Kobayashi --===============0661099586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0661099586==-- From ipfix-bounces@ietf.org Thu Nov 20 05:22:33 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB18B3A68CD; Thu, 20 Nov 2008 05:22:33 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71A053A68CD for ; Thu, 20 Nov 2008 05:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeuIzmzH0L6J for ; Thu, 20 Nov 2008 05:22:31 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 216FA3A6837 for ; Thu, 20 Nov 2008 05:22:30 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKDMRYr011005; Thu, 20 Nov 2008 22:22:27 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 20 Nov 2008 22:22:31 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <49255B80.2020000@net.in.tum.de> References: <20081120190050.8B43.17391CF2@nttv6.net> <49255B80.2020000@net.in.tum.de> Message-Id: <20081120221734.0A4C.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Thu, 20 Nov 2008 22:22:28 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator Problem Statement: Review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661099586==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org --===============0661099586== Content-Type: text/plain; charset="Shift_JIS" Content-Transfer-Encoding: quoted-printable Hi Gerhard, On Thu, 20 Nov 2008 13:43:44 +0100 Gerhard Muenz wrote: >=20 > Hi Atsushi, >=20 > Regarding the difference between IPFIX Proxy and IPFIX Distributor, the > following distinction could work: >=20 > IPFIX Proxy relays incoming transport sessions to one or multiple > Collectors. The protocols used at the input and the output may be > different, which implies that messages, templates, or records might need > to be reencoded. >=20 > IPFIX Distributor distributes incoming IPFIX Data Records to one or > multiple IPFIX Collectors. The decision to which IPFIX Collector a IPFIX > Data Record is exported may depend on filters on certain field values or > other properties derived from the IPFIX Data Record. >=20 > So, IPFIX Distributors do not perform any protocol translation (IPFIX at > input and output) while IPFIX Proxies do not filter. >=20 > What do you think? That makes sense! I will use your text. Thank you. Regards, Atsushi Kobayashi >=20 > Regards, > Gerhard >=20 > --=20 > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >=20 >=20 --=20 Atsushi Kobayashi --===============0661099586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0661099586==-- From ipfix-bounces@ietf.org Thu Nov 20 13:00:26 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CA13A6BBE; Thu, 20 Nov 2008 13:00:26 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEE03A6BC6 for ; Thu, 20 Nov 2008 13:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmbzPi5zxC-Q for ; Thu, 20 Nov 2008 13:00:21 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 6696D3A67F0 for ; Thu, 20 Nov 2008 13:00:18 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKL05bM025926; Fri, 21 Nov 2008 06:00:13 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 21 Nov 2008 06:00:15 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4921700B.1040602@net.in.tum.de> References: <4921700B.1040602@net.in.tum.de> Message-Id: <20081121050251.0A57.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Fri, 21 Nov 2008 06:00:15 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Gerhard, I appreciate your comments. On Mon, 17 Nov 2008 14:22:19 +0100 Gerhard Muenz wrote: > > Dear Atsushi, all, > > I reviewed the mediator framework draft. > > In my opinion, it already is in a very good shape. The scope is clear > and the description of the different mediator functions is comprehensive. Thank you. > > I'm not sure about the "Flow-based Collector Selection". It does not > seem to be a new function but rather a use-case of the "Flow Selection > Function" (plus Exporting Process, see comments below). > > Probably, you should not reference future drafts that are supposed to > provide technical solutions (such as IPFIX anonymization and aggregation > drafts) because we do not know how the solutions will look like. RFC3917 > does not reference any early IPFIX protocol draft, either. > Nevil pointed out same comments. For next version, I will try to add description about more conceptual idea or summary from those drafts in order to remove the references. I would rather write minimum description than detail. > Some more examples for specific mediator use-cases might be useful. > > Regards, > Gerhard > > > > > IPFIX Working Group A. Kobayashi > > Internet-Draft H. Nishida > > Intended status: Informational NTT PF Lab. > > Expires: May 8, 2009 B. Claise > > Cisco Systems > > November 4, 2008 > > > > > > > > IPFIX Mediation: Framework > > > > > > draft-ietf-ipfix-mediators-framework-01 > > > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > 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." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This Internet-Draft will expire on May 8, 2009. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 1] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Abstract > > > > This document describes a framework for an IPFIX Mediation. This > > "for an IPFIX Mediator" or "for IPFIX Mediation" > > > framework details an IPFIX Mediation reference model and the > > components of the IPFIX Mediation device (IPFIX Mediator). > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 3. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 9 > > 4. IPFIX Mediation Functional and Logical Blocks . . . . . . . . 12 > > 4.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 12 > > 4.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 12 > > 4.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 12 > > 4.3.1. Flow Selection Function . . . . . . . . . . . . . . . 12 > > 4.3.2. Flow-based Collector Selection Function . . . . . . . 13 > > 4.3.3. Aggregation Function . . . . . . . . . . . . . . . . . 13 > > 4.3.4. Correlation Function . . . . . . . . . . . . . . . . . 14 > > 4.3.5. Modification Function . . . . . . . . . . . . . . . . 15 > > 4.4. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 16 > > 4.5. Flow Expiration . . . . . . . . . . . . . . . . . . . . . 17 > > 4.6. Information Model . . . . . . . . . . . . . . . . . . . . 18 > > 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 > > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > > 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 > > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 > > Intellectual Property and Copyright Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 2] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 1. Introduction > > > > > > IPFIX Mediation reroutes, replicates, filters, aggregates, > > correlates, or modifies Flow Records/Packet Reports or changes a > > transport protocol. This document describes the framework for IPFIX > > Mediation. The motivation for the IPFIX Mediation standard comes > > from the need for flow-based measurement system support for large- > > scale networks, interdomain networks, and coexistence with > > traditional Exporters as described in detail in > > [I-D.ietf-ipfix-mediator-ps]. The standard specification requires a > > definition of IPFIX Mediation and IPFIX Mediation device (IPFIX > > Mediator). > > I would not introduce "IPFIX Mediation device" as a synonym for "IPFIX > Mediator". OK. > > > > > This document is organized as follows. Section 2 describes > > terminology related to IPFIX Mediation. Section 3 describes a high > > level reference model. Section 4 details the components of the IPFIX > > Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 3] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 2. Terminology > > > > > > The terms in this section are in line with those in the IPFIX > > specification document [RFC5101] and the PSAMP specification document > > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > > Terms from RFC5101 and psamp-protocol should not be repeated. > Terminology section could be more considered based on your suggestion as well as problem statement draft. > > Mediation are also defined with those in the IPFIX Mediator problem > > statement [I-D.ietf-ipfix-mediator-ps]. All these terms are > > capitalized in this document. > > > > Observation Point > > > > An Observation Point is a location in the network where IP packets > > can be observed. Examples include: a line to which a probe is > > attached, a shared medium, such as an Ethernet-based LAN, a single > > port of a router, or a set of interfaces (physical or logical) of > > a router. > > > > Note that every Observation Point is associated with an > > Observation Domain (defined below), and that one Observation Point > > may be a superset of several other Observation Points. For > > example, one Observation Point can be an entire line card. That > > would be the superset of the individual Observation Points at the > > line card's interfaces. > > > > Observation Domain > > > > An Observation Domain is the largest set of Observation Points for > > which Flow information can be aggregated by a Metering Process. > > For example, a router line card may be an Observation Domain if it > > is composed of several interfaces, each of which is an Observation > > Point. In the IPFIX Message it generates, the Observation Domain > > includes its Observation Domain ID, which is unique per Exporting > > Process. That way, the Collecting Process can identify the > > specific Observation Domain from the Exporter that sends the IPFIX > > Messages. Every Observation Point is associated with an > > Observation Domain. It is RECOMMENDED that Observation Domain IDs > > also be unique per IPFIX Device. > > > > Flow Key > > > > Each of the fields that: > > > > 1. belong to the packet header (e.g., destination IP address), > > > > 2. are a property of the packet itself (e.g., packet length), > > > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > > number), > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 4] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > and that are used to define a Flow are termed Flow Keys. > > > > Flow Record > > > > A Flow Record contains information about a specific Flow that was > > observed at an Observation Point. A Flow Record contains measured > > properties of the Flow (e.g., the total number of bytes for all > > the Flow's packets) and usually characteristic properties of the > > Flow (e.g., source IP address). > > > > Packet Reports > > > > Packet Reports comprise a configurable subset of a packet's input > > to the Selection Process, including the Packet Content, > > information relating to its treatment (for example, the output > > interface), and its associated selection state (for example, a > > hash of the Packet Content). > > > > Exporting Process > > > > The Exporting Process sends Flow Records to one or more Collecting > > Processes. The Flow Records are generated by one or more Metering > > Processes. > > > > Exporter > > > > A device that hosts one or more Exporting Processes is termed an > > Exporter. > > > > IPFIX Device > > > > An IPFIX Device hosts at least one Exporting Process. It may host > > further Exporting Processes and arbitrary numbers of Observation > > Points and Metering Processes. > > > > Collecting Process > > > > A Collecting Process receives Flow Records from one or more > > Exporting Processes. The Collecting Process might process or > > store received Flow Records, but such actions are out of the scope > > of this document. > > > > Collector > > > > A device that hosts one or more Collecting Processes is termed a > > Collector. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 5] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX Message > > > > An IPFIX Message is a message originating at the Exporting Process > > that carries the IPFIX records of this Exporting Process and whose > > destination is a Collecting Process. An IPFIX Message is > > encapsulated at the transport layer. > > > > Information Element > > > > An Information Element is a protocol and encoding-independent > > description of an attribute that may appear in an IPFIX Record. > > The IPFIX information model [RFC5102] defines the base set of > > Information Elements for IPFIX. The type associated with an > > Information Element indicates constraints on what it may contain > > and also determines the valid encoding mechanisms for use in > > IPFIX. > > > > IPFIX Mediation > > > > An IPFIX Mediation is a generic term for functions doing something > > for Flow Records, Packet Reports, and IPFIX Messages. IPFIX > > Mediation is located in between components: Metering Processes, > > Exporting Processes, Collecting Processes, and other applications. > > IPFIX Mediation can be included in any IPFIX Devices. IPFIX > > Mediation consists of a set of some of the following functions: > > > > * rerouting input Flow Records/Packet Reports to an appropriate > > Collecting Process > > > > * replicating input Flow Records/Packet Reports > > > > * filtering and selecting input Flow Records/Packet Reports > > > > * aggregating input Flow Records/Packet Reports based on new Flow > > Keys > > > > * correlating a set of Flow Records/Packet Reports for creating > > new Flow Records/Packet Reports with new metrics > > > > * modifying input Flow Records/Packet Reports > > > > * changing transport protocols that carry IPFIX Messages > > > > The modification of Flow Records/Packet Reports includes these > > processes: > > > > * changing the value of specified Information Elements > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 6] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > * adding new Information Elements by deriving further Flow or > > packet properties from existing fields or calculating new > > metrics > > > > * deleting specified Information Elements. > > > > IPFIX Mediation can be included in any device, such as routers, > > switches, NMS (Network Management Systems), or stand-alone > > devices. > > > > Flow-Based Collector Selection > > > > The Flow-Based Collector Selection evaluates an input Flow Record/ > > Packet Report based on the value of the specified Information > > Element and then selects a Collector for each input Flow Record/ > > Packet Report. > > > > IPFIX Mediator > > > > An IPFIX Mediator contains one or more functions defined in IPFIX > > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > > device. It also contains one or more Collecting Processes and one > > or more Exporting Processes. > > > > Original Exporter > > > > An Original Exporter is an IPFIX Device that hosts Observation > > Points where IP packets can be directly observed. > > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > > from an Original Exporter and sends IPFIX Messages to one or more > > Collectors. It may alter part of an IPFIX Message to comply with > > IPFIX Protocol specifications. It may also change the type of > > transport protocol, such as UDP, TCP, SCTP, and PR-SCTP, and > > convert a legacy protocol message to an IPFIX Message, if > > necessary. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > > Records/Packet Reports, aggregates them, then exports the > > aggregated Flow Records. > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 7] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > > Records/Packet Reports based on the result of Flow-Based Collector > > Selection. It may filter or replicate input Flow Records/Packet > > Reports, if necessary. > > > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > > a part of the data of input Flow Records/Packet Reports according > > to configured policies. It can thus, for example, hide the > > network topology information or customers' IP addresses. > > > > Intermediate Process > > > > An Intermediate Process in IPFIX Mediators can be considered as a > > partial Metering Process taken from the Metering Process in > > Original Exporters as described in [RFC3917]. > > I do not like the definition of IP as "partial MP". This creates > confusion and makes it difficult to distinguish MPs and IPs. > OK. I will remove above description. > > > > The Intermediate Process generates new sets of Data Records/Packet > > Reports from input Data Records/Packet Reports. > > > > Mediator Observation Domain > > > > An IPFIX Mediator does not host the Observation Points and > > Why should we disallow IPFIX Mediators which also have native > Observation Points? > > > Observation Domain. The Observation Domain ID in the IPFIX header > > sent by the IPFIX Mediator also indicates the largest set of > > Observation Points from the viewpoint of a Collector. However, > > This seems to be too generic. The ODID issued by the mediator should > identify the set of ODs/OPs the exported records belong to. Yes. > It does not always have to be the "largest set of OPs", it can be a subset. > Certainly, yes. > As an example, the Mediator may be configured not to merge records from > different OPs at all. In this case, we can keep the old OIDs. Or it may > be configured to merge records from a specific subset of OPs only. > Based on your comments, I think that term "Mediator Observation Domain" is unnecessary. Because term "Observation Domain" can be applied to IPFIX Mediator as well, and the meaning is not changed. Is it better to remove this term? > > this value does not indicate the physical entity of an Original > > Exporter. > > > > Transport Session Information > > > > The Transport Session is specified in [RFC5101]. In SCTP, the > > Transport Session Information is the SCTP association. In TCP and > > UDP, the Transport Session Information corresponds to a 5-tuple > > {Exporter IP address, Collector IP address, Exporter transport > > port, Collector transport port, and transport protocol}. > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 8] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 3. IPFIX Mediation Reference Model > > > > > > The figure below shows the high-level reference model for IPFIX > > Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > > the various possible scenarios that can exist in an IPFIX measurement > > system. > > > > > > +---------------------------+ +---------------------------+ > > | Collector {l} | | Collector {k} | > > |[*Application(s)] | |[*Application(s)] | > > |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > > |[Collecting Process(es)] |....|[Collecting Process(es)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ ^ > > | | | | > > | +------....----+ | > > | | | > > IPFIX (Flow Records / Packet Reports) > > | | | > > +----------------+----+-----+ +-------+-------------------+ > > |IPFIX Mediator {j} | |IPFIX Mediator {n} | > > |[*Applications(s)] | |[*Applications(s)] | > > |[Exporting Process(es)] | |[Exporting Process(es)] | > > |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > > |[Collecting Process(es)] | |[Collecting Process(es)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ > > | | | > > | +------....-----+ > > | | > > IPFIX (Flow Records / Packet Reports) > > | | > > +----------------+----------+ +----+----------------------+ > > |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > > |[Exporting Process(es)] | |[Exporting Process(es)] | > > |[Metering Process(es)] |....|[Metering Process(es)] | > > |[Observation Point(s)] | |[Observation Point(s)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ ^ > > | | | | > > Packets coming in to Observation Points > > > > Figure A: Reference Model for IPFIX Mediation. > > > > The various functional components are indicated within brackets []. > > The functional components within [*] are not part of > > [I-D.ietf-ipfix-architecture]. > > Hm. Intermediate Process as well as IPFIX reader/writer are not part of > ipfix-architecture either. > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it make sense? > BTW: IPFIX reader/writer are considered as special types of CPs and EPs. Ok. > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 9] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > The figure below shows the basic IPFIX Mediator component model. The > > IPFIX Mediator is formally defined to consist of one or more > > Collecting Processes, zero or more Intermediate Processes, and one or > > more Exporting Processes. Basically, IPFIX Mediator devices, i.e., > > IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor, and IPFIX > > Concentrator, described in [I-D.ietf-ipfix-mediator-ps], are composed > > of these components. > > > > > > IPFIX(Flow Records/Packet Reports) > > ^ > > ^ | > > +------------------------|-|---------------------+ > > | IPFIX Mediator | | | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Exporting Process (es) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Intermediate Process (es) (optional) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Collecting Process (es) |' | > > | '----------------------^--------------------' | > > +------------------------|-|---------------------+ > > | > > IPFIX(Flow Records/Packet Reports) > > > > Figure B: IPFIX Mediator Basic Component Model. > > > > An Original Exporter with a Mediation function is modeled as follows. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 10] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX (Flow Records/Packet Reports) > > ^ ^ > > +---------------------------|-|------------------------+ > > | Original Exporter | | | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Exporting Process(es) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Intermediate Process(es) |' | > > | '---------^-----------------------^---------' | > > | |Flow Record or | | > > | | Packet Reports | | > > | .------------+----------. .---------+-------------. | > > | | Metering Process {i} |..| Metering Process {n} | | > > | '------------^----------' '---------^-------------' | > > | | | | > > | .------------+----------. .---------+-------------. | > > | | Observation Point {i} |..| Observation Point {n} | | > > | '------------^----------' '---------^-------------' | > > +--------------|-----------------------|---------------+ > > | | > > Packets coming in to Observation Points > > > > Figure C: Component Model for Original Exporter with Mediation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 11] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 4. IPFIX Mediation Functional and Logical Blocks > > > > > > The section describes the details of each component and examples > > applicable to that component for IPFIX Mediation and IPFIX Mediator. > > > > 4.1. Collecting Process > > > > > > The Collecting Processes described in [RFC5101] receive Flow Records/ > > Packet Reports with information relating to their treatment in the > > Metering Process and Exporting Process in the Original Exporter, such > > as sampling rate, IPFIX header information, and Transport Session > > Information. The Collecting Processes forward the set of data to > > multiple components: Intermediate Processes and Exporting Processes. > > In other words, the processes may duplicate received Flow Records/ > > Packet Reports and forward them to multiple components in sequence or > > in parallel. > > > > 4.2. Exporting Process > > > > > > The Exporting Processes described in [RFC5101] forward Flow Records/ > > better verb for "forward"? e.g. "transmit"? > > > Packet Reports to one or multiple Collectors. The processes manage > > the reporting Template and make IPFIX Messages. > > > > 4.3. Intermediate Process > > > > > > Intermediate Processes generate new sets of Flow Records/Packet > > Reports from input Flow Records/Packet Reports with IPFIX header > > information "Export Time" and "Observation Domain ID". The processes > > I would not call it "IPFIX header information" because there are no > IPFIX Messages at the input of the Intermediate Process, only Records. > Maybe "context information collected at the Collecting Process"? > I will improve as follows. Intermediate Processes generate new sets of Flow Records/Packet Reports from input Flow Records/Packet Reports with context information collected at the Collecting Process that includes "Export Time" and "Observation Domain ID". Is it OK? > > host one of several functions defined below or a combination of them, > > in any sequence or in any set. In the case of a combination, the > > output of each function can be the input of other functions. The > > following subsections show the details of each function. > > > > 4.3.1. Flow Selection Function > > > > > > The Flow Selection function determines which input Flow Records/ > > Packet Reports are selected by matching under a filtering policy and > > then forwards them to the next processes or functions. The function > > is similar to the Selection Process described in > > [I-D.ietf-psamp-framework]. The function covers several selection > > techniques, such as property match filtering and Flow selection, > > which are described in [I-D.ietf-psamp-framework] and > > [I-D.peluso-flowselection], respectively. In property match > > filtering, if the value of a specified Information Element equals a > > configured value, the function selects Flow Records/Packet Reports to > > forward. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 12] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 4.3.2. Flow-based Collector Selection Function > > > > > > The Flow-based Collector Selection function determines to which > > Collector input Flow Records/Packet Reports are exported. The > > function may also determine the type of Transport Session. The > > This functional description conflicts with the Exporting Process. In my > opinion, the Exporting Process holds the information about the > Collectors, transport protocol etc. > > > function evaluates the value of a specified Information Element in > > input Flow Records/Packet Reports and then selects the Collector. > > So, what is the difference between Flow-Based Colelctor Selection > Function and Flow Selection Function plus Exporting Process? > > I'm not sure if Flow-based Collector Selection should be a function of > its own. I would rather say that it describes a use-case of one or > multiple Flow Selection Functions and Exporting Processes: > > +--> Flow Selector 1 -> EP 1 > ----+ > +--> Flow Selector 2 -> EP 2 > > Actually, I have been wondering in which Flow-based Collector Selection function should be located in, Metering Process or Exporting Process. And also, Flow-based Collector Selection function is special case of Selection function. Term "Flow-based Collector Selection" seems to be unnecessary. Your opinion is reasonable. I will try to write down your idea. > > These selection criteria are similar to the property match filtering > > in Mediator Selection Function. > > > > Applicable examples include exporting Flow Records/Packet Reports to > > a dedicated Collector on the basis of customers or organizations > > peering. The function classifies Flow Records/Packet Reports on the > > basis of a peering AS number, as shown in the following figure. The > > set of classified Flow Records/Packet Reports is exported to a > > dedicated Collector on the basis of the peering AS number. > > > > .----------------------------. > > | Intermediate Process | > > | .----------------------. | > > | | Flow-Based Collector | | > > | | Selection Function | | > > | | | | > > | | Peering AS #10 | | > > | | +-------------------+-+---> Collector #1 > > | | | Peering AS #20 | | > > Flow --+---+--+-------------------+-+---> Collector #2 > > Records | | | Peering AS #30 | | > > | | +-------------------+-+---> Collector #3 > > | '----------------------' | > > '----------------------------' > > > > Figure D: Exporting classified Flow Records to dedicated Collector. > > > > 4.3.3. Aggregation Function > > > > > > The Aggregation function creates aggregated Flow Records from input > > Flow Records/Packet Reports. The aggregation method is divided into > > three types: > > > > Choosing Shorter Flow Key > > > > Choosing a shorter Flow Key than the Flow Key of input Flow > > A "shorter Flow Key" would be an IP address of 8 bits. That is not what > you mean. You rather decrease the number of fields considered as Flow Keys. > OK. > > Records, such as three, two, or a single Flow Key, can create more > > "Flow Key field" > OK. > > aggregated Flow Records. The function gathers Flow Records/Packet > > Reports within a given interval time and then distinguishes Flow > > Records/Packet Reports that have common properties. If values of > > It sounds strange to distinguish records that have common properties. > You rather want to merge them. > OK. > > a given key field are the same, that means those Flow Records/ > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 13] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Packet Reports have common properties, and the function merges > > them in accordance with aggregation rules described in > > [I-D.dressler-ipfix-aggregation]. > > > > In addition, the function can create statistical data and > > subsidiary information related to the aggregated Flow Records. > > Examples include the number of input Flow Records/Packet Reports, > > the given interval time, and a set of a new Flow Key. > > "a new set of Flow Keys" > (a Flow Key is a single field!) > > > > > Time Composition > > > > Time composition is defined as aggregation with the same Flow Key > > "identical Flow Key values" > > > for long-running Flows. The function may also compute Flow > > Records statistics, such as average, maximum, and minimum value of > > each counter. The statistics help to visualize the behavior of > > traffic volume over a long time period. > > > > As another approach, the function collects Flow Records/Packet > > Reports of a shorter time period from an Original Exporter, and > > then computes these statistics. Even if output Flow Records of > > the function indicate a general time period, the accuracy of the > > minimum, maximum, and average value can be improved. > > Where is the difference to what you described in the preceding paragraph? > I indicates that it has two type of approach. One is time composition for long-running Flow. It provides the advantages: reducing the number of Flow Records and Creating new metrics average, maximum and minimum. Other is time composition for short period Flow Records. For example, short active time, e.g. 1 sec or 10 sec, is configured in Exporter intentionally, and then Mediator does time composition for certain time period, e.g. 60 sec or 300 sec, and creates new metrics average, maximum and minimum. It makes more precise maximum and minimum value, without increasing the number of Flow Records on Collector. > > > > Space Composition > > > > Space composition is defined as aggregation on a larger > > Observation Domain or on a set of Observation Points. In that > > case, a Flow key can be applied to other properties, such as > > What do you mean by "a Flow Key can be applied to "? > Maybe, it is English issue. Generally, Flow Key fields are included in Flow Records. But, in that case, other properties that are not included in Flow Records, such as Exporter IP address or Observation Domain ID, become Flow Key fields. Is it OK? > > Exporter IP address and Observation Domain ID. > > > > In addition, a group identifier indicating a spatial Observation > > Domain can also become a new Flow Key. For example, a group can > > indicate an area on an ISP network, or a link aggregation > > interface composd of physical interfaces. The group can also make > > a relation to a set of values of specified Information Elements in > > Flow Records by the configuring rule. After converting from the > > values of specified Information Elements to the group identifier, > > the function can create aggregated Flow Records by a general > > aggregation process. > > > > 4.3.4. Correlation Function > > > > > > The Correlation function creates new metrics from by evaluating the > > correlation among sets of Flow Records/Packets Records. These sets > > can be Flow Records gathered during a certain period, a pair of > > consecutive Packet Reports, or Packet Reports exported by different > > Exporters indicating the same packet. After offering new metrics, > > the function outputs Flow Records with the new metrics field. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 14] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Applicable examples are as follows. > > > > o One way delay follows from correlating Packet Reports exported > > from different Exporters on the path. > > > > o Packet interval time, or jitter, follows from correlating > > consecutive Packet Reports exported from the same Exporter. > > > > o Difference values follow from correlating Flow Records observed at > > ingress or egress interfaces. The values help to confirm the > > result of a queueing or rate-limiting function. > > > > o Average/maximum/minimum values follow from correlating each in a > > set of Flow Records. > > > > 4.3.5. Modification Function > > > > > > The Modification function modifies input Flow Records/Packet Reports > > without changing their granularity. The function can add new > > Information Elements, delete existing Information Elements, or modify > > the value of specified Information Elements. If the function > > modifies the data structure of an original Template, it also needs to > > modify the value of the "flowKeyIndicator". > > > > Adding specified Information Elements > > > > The function obtains the value of a specified Information Element > > and then adds it into Flow Records/Packet Reports. There are > > several methods to obtain the value: retrieving the value from a > > database or calculating the value based on the value of other > > Information Elements and received traffic data. > > > > Applicable examples include adding derived packet property > > parameters instead of Original Exporters. Doing that can > > remove "instead of Original Exporters" > > > compensate for traditional Exporters or probes unable to add > > packet property parameters. Therefore, Collectors do not need to > > recognize the difference among implementations of routers from > > several vendors or among Exporter types, such as router, switch, > > or probe. Typical derived packet property parameters include the > > following. > > > > * The "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] > > indicates the egress router of a network domain. That is > > useful for making a traffic matrix that covers the whole > > network domain. > > > > * The BGP Community value indicates the same group of destination > > or source IP addresses. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 15] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > * The "mplsVpnRouteDistinguisher" described in [RFC5102], which > > cannot be extracted from the core router in MPLS networks, > > indicates the VPN customer's identification. Network operators > > can monitor the traffic behavior of each customer by adding > > "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports. > > > > Deleting specified Information Elements > > > > This function deletes existing Information Elements according to > > instruction rules, which indicate whether an Information Element > > should be removed. > > > > Applicable examples include hiding network topology information > > and private information. In the case of IPFIX exporting across > > domains, the function can avoid making a vulnerability by deleting > > unnecessary Information Elements. Examples of network topology > > information include "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4| > > v6}Address", and "bgp{Next|Prev}AdjacentAsNumber", described in > > [RFC5102]. In addition, MPLS-related Information Elements, such > > as "mplsLabelStackSection", are useless for customers in the case > > of feeding Flow Records/Packet Reports to VPN customers. > > > > Modifying the value of specified Information Elements > > > > This function modifies the value of specified Information > > Elements. > > > > Applicable examples include anonymizing customers' private > > information, such as IP address and port number, according to a > > privacy protection policy. Several annonymization techniques are > > described in [I-D.boschi-ipfix-anon]. The function also reports > > anonymization methods and part of anonymized data as subsidiary > > information. > > > > 4.4. IPFIX File Writer/Reader > > > > > > The IPFIX File Writer stores input Flow Records/Packet Reports from > > any process in a storage system. If received Flow Records/Packet > > It's a "file system". > > > Reports include uninteresting Information Elements, the Modification > > Function can delete these elements before the IPFIX File Writer > > handles them. Therefore, IPFIX File Writers can accept input from > > any process. In either case, input needs to include the IPFIX header > > Remove the whole sentence "Therefore,..." > > > information and the Transport Session Information along with Flow > > Records/Packet Reports. > > Why does the File Writer require header information and transport > session information as input? > We should not specify additional restrictions for the File Writer here. > Also, there are cases where there are no headers and no transport > sessions, e.g. if the writer is linked to a Metering Process. > OK. But, if I'm not mistaken, I think that IPFIX file format includes session information and Observation Domain ID. I don't intend to add other restrictions for the File Writer. I will read more IPFIX file format draft. > > > > In contrast, the IPFIX File Reader retrieves stored Flow Records/ > > Packet Reports when operators want to retrieve past Flow Records/ > > Packet Reports on the basis of a given time period. If the data > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 16] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > structure of output Flow Records/Packet Reports from the IPFIX File > > Reader is different from what operators want, the Modification > > function can modify the data structure. Therefore, the output of > > IPFIX File Readers can be input to any components. The IPFIX File > > Writer/Reader are described in [I-D.ietf-ipfix-file] in detail. > > > > The figure shows the IPFIX component model with IPFIX File Writer/ > > Reader. IPFIX File Writer/Reader are located in the same position of > > Exporting Process/Collecting Process, respectively. > > According to ipfix-file, IPFIX File Writer/Reader operate as EP/CP. So, > "located in the same position of EP/CP" is not precise language because > writer/reader are specific types of EPs and CPs. > OK. > > > > IPFIX (Flow Records/Packet Reports) > > ^ > > ^ | > > .----------------------|-+--------------------. > > .-----------------------+---------------------.| > > | Exporting Process (es) / IPFIX File Writer |' > > '----^------------------^---------------------' > > | | | > > | .-------------|-+--------------------. > > | .--------------+---------------------.| > > | | Intermediate Process (es) |' > > | '--------------^-^-------------------' > > | | | > > .---+------------------|-+--------------------. > > .-----------------------+---------------------.| > > | Collecting Process (es) / IPFIX File Reader |' > > '-----------------------^---------------------' > > | > > IPFIX (Flow Records/Packet Reports) > > > > > > Figure E: IPFIX Mediator Component Model with IPFIX File Writer/ > > Reader. > > > > 4.5. Flow Expiration > > > > > > The Aggregation function needs expiration conditions to export cached > > Flow Records. These conditions are described in > > [I-D.ietf-ipfix-architecture]. In the case of IPFIX Mediation, these > > conditions are as follows: > > > > o If there are no input/received Flow Records/Packet Reports > > belonging to a cached Flow for a certain time period, aggregated > > Flow Records will expire. This time period should be configurable > > at the Intermediate Process. > > > > o If the IPFIX Mediator experiences resource constraints, aggregated > > Flow Records may prematurely expire (e.g., lack of memory to store > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 17] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Flow Records). > > > > o For long-running Flows, the Intermediate Process should expire the > > Flow on a regular basis or based on some expiration policy. This > > periodicity or expiration policy should be configurable at the > > Intermediate Process. > > > > The Correlation function also needs similar expiration conditions. > > However, when cached Flow Records/Packet Reports prematurely expire > > and the function can not compute the correlation among them, cached > > Flow Records/Packet reports may be discarded. > > > > 4.6. Information Model > > > > > > IPFIX Mediation reuse the general information model from [RFC5101] > > and from [I-D.ietf-psamp-info]. The following new Information > > Elements for IPFIX Mediation are also needed. > > > > +-----+---------------------------+-----+---------------------------+ > > | ID | Name | ID | Name | > > +-----+---------------------------+-----+---------------------------+ > > | XXX | averageBitRate | XXX | averagePacketsRate | > > | XXX | minimumBitRate | XXX | minimumPacketsRate | > > | XXX | maximumBitRate | XXX | maximumPacketsRate | > > +-----+---------------------------+-----+---------------------------+ > > I'm not sure if we should start exporting "rate" IEs. Rates do not > represent stable metrics. It's always better to measure "counts". So, I > suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. > Certainly, yes. If proposing "maximumPacketDeltaCount", we also need to propose other Information Element that shows time period of original Flow Records. Because the start time and end time of Flow Record are changed in Mediator. Collector can not recognize the delta time. What do yo think? > I do not understand why average rate is needed. You easily get the > average rate by dividing the delta count of the entire measurement > interval by the interval length. > Actually, Yes. But, this subsection is pointed out yesterday at IPFIX meeting. The definition of Information Elements should not be described in framework draft as Informational. Therefore, I will write down more conceptional idea only. > > > > 4.7. Examples > > > > > > As example, in case of Intermediate Processes having different > > functions, a Collecting Process/IPFIX File Reader replicates Flow > > Records/Packet Reports, if necessary, and forwards them to a suitable > > Intermediate Process/Exporting Process. Example figure is shown > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 18] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX IPFIX IPFIX > > ^ ^ ^ > > | | | > > .------------. .-----+-------. .-----+-------. .------+------. > > | IPFIX File | | Exporting | | Exporting | | Exporting | > > | Writer | | Process {i}| | Process {j}|....| Process {n}| > > '-----^-^----' '-----^-------' '-----^-------' '------^------' > > | | | | | > > | +-------------+ | Flow Records > > | Flow Records / Packet Reports | > > | .------+-------. .-----+--------. .------+-------. > > | | Intermediate | | Intermediate | | Intermediate | > > | | Process {l} | | Process {m} | | Process {p} | > > | | | | |...| | > > | | Flow-based | | Flow-based | | | > > | | Collector | | Collector | | | > > | | Selection | | Selection | | | > > Flow Records | ^ | | ^ | | | > > | | | | | | | | | > > | | Correlation | | Modification| | Modification| > > | | ^ | | ^ | | ^ | > > | | | | | | | | | | > > | | Selection | | Aggregation |...| Selection | > > | | ^ | | ^ ^ | | ^ | > > | '------|-------' '-----|-|------' '------|-------' > > | | | | | > > | +---------------+ | Flow Records > > | | | | > > | Flow Records / Packet Reports | > > .------+------. .------+------. .------+------. .-----+------. > > | Collecting | | Collecting | | Collecting | | IPFIX File | > > | Process {i}| | Process {j}|...| Process {n}| | Reader | > > '------^------' '------^------' '------^------' '------------' > > | | | > > IPFIX IPFIX IPFIX > > > > Figure F: Functional Block Examples for IPFIX Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 19] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 5. Security Considerations > > > > > > IPFIX Mediators use the IPFIX protocol. Security considerations > > about Flow Records are described in [RFC5101]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 20] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 6. IANA Considerations > > > > > > This document has no actions for IANA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 21] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 7. References > > > > > > 7.1. Normative References > > > > > > [I-D.ietf-ipfix-architecture] > > Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > > "Architecture for IP Flow Information Export", > > draft-ietf-I-D.ietf-ipfix-architectureitecture-12.txt(work > > in progress) , September 2006. > > > > [I-D.ietf-psamp-framework] > > Duffield, N., "A Framework for Packet Selection and > > Reporting", draft-ietf-psamp-framework-13.txt , June 2008. > > > > [I-D.ietf-psamp-info] > > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > > Carle, "Information Model for Packet Sampling Exports", > > draft-ietf-psamp-info-11.txt (work in progress) , > > October 2008. > > > > [I-D.ietf-psamp-protocol] > > Claise, B., Quittek, J., and A. Johnson, "Packet Sampling > > (PSAMP) Protocol Specifications", > > draft-ietf-psamp-protocol-09.txt , December 2007. > > > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > > "Requirements for IP Flow Information Export(IPFIX)", > > October 2004. > > > > [RFC5101] Claise, B., "Specification of the IP Flow Information > > Export (IPFIX) Protocol for the Exchange of IP Traffic > > Flow Information", January 2008. > > > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > > Meyer, "Information Model for IP Flow Information Export", > > January 2008. > > > > 7.2. Informative References > > > > > > [I-D.boschi-ipfix-anon] > > Boschi, E. and B. Trammell, "IP Flow Anonymisation > > Support", draft-boschi-ipfix-anon-01.txt (work in > > progress) , July 2008. > > > > [I-D.dressler-ipfix-aggregation] > > Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, > > "IPFIX Aggregation", > > draft-dressler-ipfix-aggregation-05.txt (work in > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 22] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > progress) , July 2008. > > > > [I-D.ietf-ipfix-file] > > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > > Wagner, "An IPFIX-Based File Format", > > draft-ietf-ipfix-file-03.txt(work in progress) , > > October 2008. > > > > [I-D.ietf-ipfix-mediator-ps] > > Kobayashi, A., Nishida, H., Sommer, C., Dressler, F., > > Stephan, E., and B. Claise, "IPFIX Mediation: Problem > > Statement", > > draft-ietf-ipfix-mediation-problem-statement-01.txt(work > > in progress) , September 2008. > > > > [I-D.peluso-flowselection] > > Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow > > selection Techniques", > > draft-peluso-flowselection-tech-01.txt(work in progress) , > > November 2007. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 23] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Appendix A. Acknowledgements > > > > > > The authors gratefully acknowledge the contributions of > > > > Keisuke Ishibashi, > > Tsuyoshi Kondoh, and > > Daisuke Matsubara. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 24] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Authors' Addresses > > > > Atsushi Kobayashi > > NTT Information Sharing Platform Laboratories > > 3-9-11 Midori-cho > > Musashino-shi, Tokyo 180-8585 > > Japan > > > > Phone: +81-422-59-3978 > > Email: akoba@nttv6.net > > > > > > Haruhiko Nishida > > NTT Information Sharing Platform Laboratories > > 3-9-11 Midori-cho > > Musashino-shi, Tokyo 180-8585 > > Japan > > > > Phone: +81-422-59-3978 > > Email: nishida.haruhiko@lab.ntt.co.jp > > > > > > Benoit Claise > > Cisco Systems > > De Kleetlaan 6a b1 > > Diegem 1831 > > Belgium > > > > Phone: +32 2 704 5622 > > Email: bclaise@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 25] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Full Copyright Statement > > > > Copyright (C) The IETF Trust (2008). > > > > This document is subject to the rights, licenses and restrictions > > contained in BCP 78, and except as set forth therein, the authors > > retain all their rights. > > > > This document and the information contained herein are provided on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > Intellectual Property > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might be claimed to > > pertain to the implementation or use of the technology described in > > this document or the extent to which any license under such rights > > might or might not be available; nor does it represent that it has > > made any independent effort to identify any such rights. Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR repository at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 26] -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 13:00:26 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CA13A6BBE; Thu, 20 Nov 2008 13:00:26 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEE03A6BC6 for ; Thu, 20 Nov 2008 13:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmbzPi5zxC-Q for ; Thu, 20 Nov 2008 13:00:21 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 6696D3A67F0 for ; Thu, 20 Nov 2008 13:00:18 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAKL05bM025926; Fri, 21 Nov 2008 06:00:13 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 21 Nov 2008 06:00:15 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4921700B.1040602@net.in.tum.de> References: <4921700B.1040602@net.in.tum.de> Message-Id: <20081121050251.0A57.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Fri, 21 Nov 2008 06:00:15 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Dear Gerhard, I appreciate your comments. On Mon, 17 Nov 2008 14:22:19 +0100 Gerhard Muenz wrote: > > Dear Atsushi, all, > > I reviewed the mediator framework draft. > > In my opinion, it already is in a very good shape. The scope is clear > and the description of the different mediator functions is comprehensive. Thank you. > > I'm not sure about the "Flow-based Collector Selection". It does not > seem to be a new function but rather a use-case of the "Flow Selection > Function" (plus Exporting Process, see comments below). > > Probably, you should not reference future drafts that are supposed to > provide technical solutions (such as IPFIX anonymization and aggregation > drafts) because we do not know how the solutions will look like. RFC3917 > does not reference any early IPFIX protocol draft, either. > Nevil pointed out same comments. For next version, I will try to add description about more conceptual idea or summary from those drafts in order to remove the references. I would rather write minimum description than detail. > Some more examples for specific mediator use-cases might be useful. > > Regards, > Gerhard > > > > > IPFIX Working Group A. Kobayashi > > Internet-Draft H. Nishida > > Intended status: Informational NTT PF Lab. > > Expires: May 8, 2009 B. Claise > > Cisco Systems > > November 4, 2008 > > > > > > > > IPFIX Mediation: Framework > > > > > > draft-ietf-ipfix-mediators-framework-01 > > > > > > Status of this Memo > > > > By submitting this Internet-Draft, each author represents that any > > applicable patent or other IPR claims of which he or she is aware > > have been or will be disclosed, and any of which he or she becomes > > aware will be disclosed, in accordance with Section 6 of BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > 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." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > > > This Internet-Draft will expire on May 8, 2009. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 1] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Abstract > > > > This document describes a framework for an IPFIX Mediation. This > > "for an IPFIX Mediator" or "for IPFIX Mediation" > > > framework details an IPFIX Mediation reference model and the > > components of the IPFIX Mediation device (IPFIX Mediator). > > > > > > Table of Contents > > > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > > 3. IPFIX Mediation Reference Model . . . . . . . . . . . . . . . 9 > > 4. IPFIX Mediation Functional and Logical Blocks . . . . . . . . 12 > > 4.1. Collecting Process . . . . . . . . . . . . . . . . . . . . 12 > > 4.2. Exporting Process . . . . . . . . . . . . . . . . . . . . 12 > > 4.3. Intermediate Process . . . . . . . . . . . . . . . . . . . 12 > > 4.3.1. Flow Selection Function . . . . . . . . . . . . . . . 12 > > 4.3.2. Flow-based Collector Selection Function . . . . . . . 13 > > 4.3.3. Aggregation Function . . . . . . . . . . . . . . . . . 13 > > 4.3.4. Correlation Function . . . . . . . . . . . . . . . . . 14 > > 4.3.5. Modification Function . . . . . . . . . . . . . . . . 15 > > 4.4. IPFIX File Writer/Reader . . . . . . . . . . . . . . . . . 16 > > 4.5. Flow Expiration . . . . . . . . . . . . . . . . . . . . . 17 > > 4.6. Information Model . . . . . . . . . . . . . . . . . . . . 18 > > 4.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 > > 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 > > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 > > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 > > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 22 > > 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 > > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 > > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 > > Intellectual Property and Copyright Statements . . . . . . . . . . 26 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 2] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 1. Introduction > > > > > > IPFIX Mediation reroutes, replicates, filters, aggregates, > > correlates, or modifies Flow Records/Packet Reports or changes a > > transport protocol. This document describes the framework for IPFIX > > Mediation. The motivation for the IPFIX Mediation standard comes > > from the need for flow-based measurement system support for large- > > scale networks, interdomain networks, and coexistence with > > traditional Exporters as described in detail in > > [I-D.ietf-ipfix-mediator-ps]. The standard specification requires a > > definition of IPFIX Mediation and IPFIX Mediation device (IPFIX > > Mediator). > > I would not introduce "IPFIX Mediation device" as a synonym for "IPFIX > Mediator". OK. > > > > > This document is organized as follows. Section 2 describes > > terminology related to IPFIX Mediation. Section 3 describes a high > > level reference model. Section 4 details the components of the IPFIX > > Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 3] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 2. Terminology > > > > > > The terms in this section are in line with those in the IPFIX > > specification document [RFC5101] and the PSAMP specification document > > [I-D.ietf-psamp-protocol]. Additional terms required for the IPFIX > > Terms from RFC5101 and psamp-protocol should not be repeated. > Terminology section could be more considered based on your suggestion as well as problem statement draft. > > Mediation are also defined with those in the IPFIX Mediator problem > > statement [I-D.ietf-ipfix-mediator-ps]. All these terms are > > capitalized in this document. > > > > Observation Point > > > > An Observation Point is a location in the network where IP packets > > can be observed. Examples include: a line to which a probe is > > attached, a shared medium, such as an Ethernet-based LAN, a single > > port of a router, or a set of interfaces (physical or logical) of > > a router. > > > > Note that every Observation Point is associated with an > > Observation Domain (defined below), and that one Observation Point > > may be a superset of several other Observation Points. For > > example, one Observation Point can be an entire line card. That > > would be the superset of the individual Observation Points at the > > line card's interfaces. > > > > Observation Domain > > > > An Observation Domain is the largest set of Observation Points for > > which Flow information can be aggregated by a Metering Process. > > For example, a router line card may be an Observation Domain if it > > is composed of several interfaces, each of which is an Observation > > Point. In the IPFIX Message it generates, the Observation Domain > > includes its Observation Domain ID, which is unique per Exporting > > Process. That way, the Collecting Process can identify the > > specific Observation Domain from the Exporter that sends the IPFIX > > Messages. Every Observation Point is associated with an > > Observation Domain. It is RECOMMENDED that Observation Domain IDs > > also be unique per IPFIX Device. > > > > Flow Key > > > > Each of the fields that: > > > > 1. belong to the packet header (e.g., destination IP address), > > > > 2. are a property of the packet itself (e.g., packet length), > > > > 3. are derived from packet treatment (e.g., Autonomous System (AS) > > number), > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 4] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > and that are used to define a Flow are termed Flow Keys. > > > > Flow Record > > > > A Flow Record contains information about a specific Flow that was > > observed at an Observation Point. A Flow Record contains measured > > properties of the Flow (e.g., the total number of bytes for all > > the Flow's packets) and usually characteristic properties of the > > Flow (e.g., source IP address). > > > > Packet Reports > > > > Packet Reports comprise a configurable subset of a packet's input > > to the Selection Process, including the Packet Content, > > information relating to its treatment (for example, the output > > interface), and its associated selection state (for example, a > > hash of the Packet Content). > > > > Exporting Process > > > > The Exporting Process sends Flow Records to one or more Collecting > > Processes. The Flow Records are generated by one or more Metering > > Processes. > > > > Exporter > > > > A device that hosts one or more Exporting Processes is termed an > > Exporter. > > > > IPFIX Device > > > > An IPFIX Device hosts at least one Exporting Process. It may host > > further Exporting Processes and arbitrary numbers of Observation > > Points and Metering Processes. > > > > Collecting Process > > > > A Collecting Process receives Flow Records from one or more > > Exporting Processes. The Collecting Process might process or > > store received Flow Records, but such actions are out of the scope > > of this document. > > > > Collector > > > > A device that hosts one or more Collecting Processes is termed a > > Collector. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 5] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX Message > > > > An IPFIX Message is a message originating at the Exporting Process > > that carries the IPFIX records of this Exporting Process and whose > > destination is a Collecting Process. An IPFIX Message is > > encapsulated at the transport layer. > > > > Information Element > > > > An Information Element is a protocol and encoding-independent > > description of an attribute that may appear in an IPFIX Record. > > The IPFIX information model [RFC5102] defines the base set of > > Information Elements for IPFIX. The type associated with an > > Information Element indicates constraints on what it may contain > > and also determines the valid encoding mechanisms for use in > > IPFIX. > > > > IPFIX Mediation > > > > An IPFIX Mediation is a generic term for functions doing something > > for Flow Records, Packet Reports, and IPFIX Messages. IPFIX > > Mediation is located in between components: Metering Processes, > > Exporting Processes, Collecting Processes, and other applications. > > IPFIX Mediation can be included in any IPFIX Devices. IPFIX > > Mediation consists of a set of some of the following functions: > > > > * rerouting input Flow Records/Packet Reports to an appropriate > > Collecting Process > > > > * replicating input Flow Records/Packet Reports > > > > * filtering and selecting input Flow Records/Packet Reports > > > > * aggregating input Flow Records/Packet Reports based on new Flow > > Keys > > > > * correlating a set of Flow Records/Packet Reports for creating > > new Flow Records/Packet Reports with new metrics > > > > * modifying input Flow Records/Packet Reports > > > > * changing transport protocols that carry IPFIX Messages > > > > The modification of Flow Records/Packet Reports includes these > > processes: > > > > * changing the value of specified Information Elements > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 6] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > * adding new Information Elements by deriving further Flow or > > packet properties from existing fields or calculating new > > metrics > > > > * deleting specified Information Elements. > > > > IPFIX Mediation can be included in any device, such as routers, > > switches, NMS (Network Management Systems), or stand-alone > > devices. > > > > Flow-Based Collector Selection > > > > The Flow-Based Collector Selection evaluates an input Flow Record/ > > Packet Report based on the value of the specified Information > > Element and then selects a Collector for each input Flow Record/ > > Packet Report. > > > > IPFIX Mediator > > > > An IPFIX Mediator contains one or more functions defined in IPFIX > > Mediation. The IPFIX Mediator can be a stand-alone or a virtual > > device. It also contains one or more Collecting Processes and one > > or more Exporting Processes. > > > > Original Exporter > > > > An Original Exporter is an IPFIX Device that hosts Observation > > Points where IP packets can be directly observed. > > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that receives IPFIX Messages > > from an Original Exporter and sends IPFIX Messages to one or more > > Collectors. It may alter part of an IPFIX Message to comply with > > IPFIX Protocol specifications. It may also change the type of > > transport protocol, such as UDP, TCP, SCTP, and PR-SCTP, and > > convert a legacy protocol message to an IPFIX Message, if > > necessary. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that receives Flow > > Records/Packet Reports, aggregates them, then exports the > > aggregated Flow Records. > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 7] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that reroutes input Flow > > Records/Packet Reports based on the result of Flow-Based Collector > > Selection. It may filter or replicate input Flow Records/Packet > > Reports, if necessary. > > > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that screens out > > a part of the data of input Flow Records/Packet Reports according > > to configured policies. It can thus, for example, hide the > > network topology information or customers' IP addresses. > > > > Intermediate Process > > > > An Intermediate Process in IPFIX Mediators can be considered as a > > partial Metering Process taken from the Metering Process in > > Original Exporters as described in [RFC3917]. > > I do not like the definition of IP as "partial MP". This creates > confusion and makes it difficult to distinguish MPs and IPs. > OK. I will remove above description. > > > > The Intermediate Process generates new sets of Data Records/Packet > > Reports from input Data Records/Packet Reports. > > > > Mediator Observation Domain > > > > An IPFIX Mediator does not host the Observation Points and > > Why should we disallow IPFIX Mediators which also have native > Observation Points? > > > Observation Domain. The Observation Domain ID in the IPFIX header > > sent by the IPFIX Mediator also indicates the largest set of > > Observation Points from the viewpoint of a Collector. However, > > This seems to be too generic. The ODID issued by the mediator should > identify the set of ODs/OPs the exported records belong to. Yes. > It does not always have to be the "largest set of OPs", it can be a subset. > Certainly, yes. > As an example, the Mediator may be configured not to merge records from > different OPs at all. In this case, we can keep the old OIDs. Or it may > be configured to merge records from a specific subset of OPs only. > Based on your comments, I think that term "Mediator Observation Domain" is unnecessary. Because term "Observation Domain" can be applied to IPFIX Mediator as well, and the meaning is not changed. Is it better to remove this term? > > this value does not indicate the physical entity of an Original > > Exporter. > > > > Transport Session Information > > > > The Transport Session is specified in [RFC5101]. In SCTP, the > > Transport Session Information is the SCTP association. In TCP and > > UDP, the Transport Session Information corresponds to a 5-tuple > > {Exporter IP address, Collector IP address, Exporter transport > > port, Collector transport port, and transport protocol}. > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 8] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 3. IPFIX Mediation Reference Model > > > > > > The figure below shows the high-level reference model for IPFIX > > Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > > the various possible scenarios that can exist in an IPFIX measurement > > system. > > > > > > +---------------------------+ +---------------------------+ > > | Collector {l} | | Collector {k} | > > |[*Application(s)] | |[*Application(s)] | > > |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > > |[Collecting Process(es)] |....|[Collecting Process(es)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ ^ > > | | | | > > | +------....----+ | > > | | | > > IPFIX (Flow Records / Packet Reports) > > | | | > > +----------------+----+-----+ +-------+-------------------+ > > |IPFIX Mediator {j} | |IPFIX Mediator {n} | > > |[*Applications(s)] | |[*Applications(s)] | > > |[Exporting Process(es)] | |[Exporting Process(es)] | > > |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > > |[Collecting Process(es)] | |[Collecting Process(es)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ > > | | | > > | +------....-----+ > > | | > > IPFIX (Flow Records / Packet Reports) > > | | > > +----------------+----------+ +----+----------------------+ > > |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > > |[Exporting Process(es)] | |[Exporting Process(es)] | > > |[Metering Process(es)] |....|[Metering Process(es)] | > > |[Observation Point(s)] | |[Observation Point(s)] | > > +---------------------------+ +---------------------------+ > > ^ ^ ^ ^ > > | | | | > > Packets coming in to Observation Points > > > > Figure A: Reference Model for IPFIX Mediation. > > > > The various functional components are indicated within brackets []. > > The functional components within [*] are not part of > > [I-D.ietf-ipfix-architecture]. > > Hm. Intermediate Process as well as IPFIX reader/writer are not part of > ipfix-architecture either. > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it make sense? > BTW: IPFIX reader/writer are considered as special types of CPs and EPs. Ok. > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 9] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > The figure below shows the basic IPFIX Mediator component model. The > > IPFIX Mediator is formally defined to consist of one or more > > Collecting Processes, zero or more Intermediate Processes, and one or > > more Exporting Processes. Basically, IPFIX Mediator devices, i.e., > > IPFIX Proxy, IPFIX Masquerading Proxy, IPFIX Distributor, and IPFIX > > Concentrator, described in [I-D.ietf-ipfix-mediator-ps], are composed > > of these components. > > > > > > IPFIX(Flow Records/Packet Reports) > > ^ > > ^ | > > +------------------------|-|---------------------+ > > | IPFIX Mediator | | | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Exporting Process (es) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Intermediate Process (es) (optional) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Collecting Process (es) |' | > > | '----------------------^--------------------' | > > +------------------------|-|---------------------+ > > | > > IPFIX(Flow Records/Packet Reports) > > > > Figure B: IPFIX Mediator Basic Component Model. > > > > An Original Exporter with a Mediation function is modeled as follows. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 10] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX (Flow Records/Packet Reports) > > ^ ^ > > +---------------------------|-|------------------------+ > > | Original Exporter | | | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Exporting Process(es) |' | > > | '----------------------^--------------------' | > > | | | | > > | .---------------------|-+-------------------. | > > | .----------------------+--------------------.| | > > | | Intermediate Process(es) |' | > > | '---------^-----------------------^---------' | > > | |Flow Record or | | > > | | Packet Reports | | > > | .------------+----------. .---------+-------------. | > > | | Metering Process {i} |..| Metering Process {n} | | > > | '------------^----------' '---------^-------------' | > > | | | | > > | .------------+----------. .---------+-------------. | > > | | Observation Point {i} |..| Observation Point {n} | | > > | '------------^----------' '---------^-------------' | > > +--------------|-----------------------|---------------+ > > | | > > Packets coming in to Observation Points > > > > Figure C: Component Model for Original Exporter with Mediation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 11] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 4. IPFIX Mediation Functional and Logical Blocks > > > > > > The section describes the details of each component and examples > > applicable to that component for IPFIX Mediation and IPFIX Mediator. > > > > 4.1. Collecting Process > > > > > > The Collecting Processes described in [RFC5101] receive Flow Records/ > > Packet Reports with information relating to their treatment in the > > Metering Process and Exporting Process in the Original Exporter, such > > as sampling rate, IPFIX header information, and Transport Session > > Information. The Collecting Processes forward the set of data to > > multiple components: Intermediate Processes and Exporting Processes. > > In other words, the processes may duplicate received Flow Records/ > > Packet Reports and forward them to multiple components in sequence or > > in parallel. > > > > 4.2. Exporting Process > > > > > > The Exporting Processes described in [RFC5101] forward Flow Records/ > > better verb for "forward"? e.g. "transmit"? > > > Packet Reports to one or multiple Collectors. The processes manage > > the reporting Template and make IPFIX Messages. > > > > 4.3. Intermediate Process > > > > > > Intermediate Processes generate new sets of Flow Records/Packet > > Reports from input Flow Records/Packet Reports with IPFIX header > > information "Export Time" and "Observation Domain ID". The processes > > I would not call it "IPFIX header information" because there are no > IPFIX Messages at the input of the Intermediate Process, only Records. > Maybe "context information collected at the Collecting Process"? > I will improve as follows. Intermediate Processes generate new sets of Flow Records/Packet Reports from input Flow Records/Packet Reports with context information collected at the Collecting Process that includes "Export Time" and "Observation Domain ID". Is it OK? > > host one of several functions defined below or a combination of them, > > in any sequence or in any set. In the case of a combination, the > > output of each function can be the input of other functions. The > > following subsections show the details of each function. > > > > 4.3.1. Flow Selection Function > > > > > > The Flow Selection function determines which input Flow Records/ > > Packet Reports are selected by matching under a filtering policy and > > then forwards them to the next processes or functions. The function > > is similar to the Selection Process described in > > [I-D.ietf-psamp-framework]. The function covers several selection > > techniques, such as property match filtering and Flow selection, > > which are described in [I-D.ietf-psamp-framework] and > > [I-D.peluso-flowselection], respectively. In property match > > filtering, if the value of a specified Information Element equals a > > configured value, the function selects Flow Records/Packet Reports to > > forward. > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 12] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 4.3.2. Flow-based Collector Selection Function > > > > > > The Flow-based Collector Selection function determines to which > > Collector input Flow Records/Packet Reports are exported. The > > function may also determine the type of Transport Session. The > > This functional description conflicts with the Exporting Process. In my > opinion, the Exporting Process holds the information about the > Collectors, transport protocol etc. > > > function evaluates the value of a specified Information Element in > > input Flow Records/Packet Reports and then selects the Collector. > > So, what is the difference between Flow-Based Colelctor Selection > Function and Flow Selection Function plus Exporting Process? > > I'm not sure if Flow-based Collector Selection should be a function of > its own. I would rather say that it describes a use-case of one or > multiple Flow Selection Functions and Exporting Processes: > > +--> Flow Selector 1 -> EP 1 > ----+ > +--> Flow Selector 2 -> EP 2 > > Actually, I have been wondering in which Flow-based Collector Selection function should be located in, Metering Process or Exporting Process. And also, Flow-based Collector Selection function is special case of Selection function. Term "Flow-based Collector Selection" seems to be unnecessary. Your opinion is reasonable. I will try to write down your idea. > > These selection criteria are similar to the property match filtering > > in Mediator Selection Function. > > > > Applicable examples include exporting Flow Records/Packet Reports to > > a dedicated Collector on the basis of customers or organizations > > peering. The function classifies Flow Records/Packet Reports on the > > basis of a peering AS number, as shown in the following figure. The > > set of classified Flow Records/Packet Reports is exported to a > > dedicated Collector on the basis of the peering AS number. > > > > .----------------------------. > > | Intermediate Process | > > | .----------------------. | > > | | Flow-Based Collector | | > > | | Selection Function | | > > | | | | > > | | Peering AS #10 | | > > | | +-------------------+-+---> Collector #1 > > | | | Peering AS #20 | | > > Flow --+---+--+-------------------+-+---> Collector #2 > > Records | | | Peering AS #30 | | > > | | +-------------------+-+---> Collector #3 > > | '----------------------' | > > '----------------------------' > > > > Figure D: Exporting classified Flow Records to dedicated Collector. > > > > 4.3.3. Aggregation Function > > > > > > The Aggregation function creates aggregated Flow Records from input > > Flow Records/Packet Reports. The aggregation method is divided into > > three types: > > > > Choosing Shorter Flow Key > > > > Choosing a shorter Flow Key than the Flow Key of input Flow > > A "shorter Flow Key" would be an IP address of 8 bits. That is not what > you mean. You rather decrease the number of fields considered as Flow Keys. > OK. > > Records, such as three, two, or a single Flow Key, can create more > > "Flow Key field" > OK. > > aggregated Flow Records. The function gathers Flow Records/Packet > > Reports within a given interval time and then distinguishes Flow > > Records/Packet Reports that have common properties. If values of > > It sounds strange to distinguish records that have common properties. > You rather want to merge them. > OK. > > a given key field are the same, that means those Flow Records/ > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 13] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Packet Reports have common properties, and the function merges > > them in accordance with aggregation rules described in > > [I-D.dressler-ipfix-aggregation]. > > > > In addition, the function can create statistical data and > > subsidiary information related to the aggregated Flow Records. > > Examples include the number of input Flow Records/Packet Reports, > > the given interval time, and a set of a new Flow Key. > > "a new set of Flow Keys" > (a Flow Key is a single field!) > > > > > Time Composition > > > > Time composition is defined as aggregation with the same Flow Key > > "identical Flow Key values" > > > for long-running Flows. The function may also compute Flow > > Records statistics, such as average, maximum, and minimum value of > > each counter. The statistics help to visualize the behavior of > > traffic volume over a long time period. > > > > As another approach, the function collects Flow Records/Packet > > Reports of a shorter time period from an Original Exporter, and > > then computes these statistics. Even if output Flow Records of > > the function indicate a general time period, the accuracy of the > > minimum, maximum, and average value can be improved. > > Where is the difference to what you described in the preceding paragraph? > I indicates that it has two type of approach. One is time composition for long-running Flow. It provides the advantages: reducing the number of Flow Records and Creating new metrics average, maximum and minimum. Other is time composition for short period Flow Records. For example, short active time, e.g. 1 sec or 10 sec, is configured in Exporter intentionally, and then Mediator does time composition for certain time period, e.g. 60 sec or 300 sec, and creates new metrics average, maximum and minimum. It makes more precise maximum and minimum value, without increasing the number of Flow Records on Collector. > > > > Space Composition > > > > Space composition is defined as aggregation on a larger > > Observation Domain or on a set of Observation Points. In that > > case, a Flow key can be applied to other properties, such as > > What do you mean by "a Flow Key can be applied to "? > Maybe, it is English issue. Generally, Flow Key fields are included in Flow Records. But, in that case, other properties that are not included in Flow Records, such as Exporter IP address or Observation Domain ID, become Flow Key fields. Is it OK? > > Exporter IP address and Observation Domain ID. > > > > In addition, a group identifier indicating a spatial Observation > > Domain can also become a new Flow Key. For example, a group can > > indicate an area on an ISP network, or a link aggregation > > interface composd of physical interfaces. The group can also make > > a relation to a set of values of specified Information Elements in > > Flow Records by the configuring rule. After converting from the > > values of specified Information Elements to the group identifier, > > the function can create aggregated Flow Records by a general > > aggregation process. > > > > 4.3.4. Correlation Function > > > > > > The Correlation function creates new metrics from by evaluating the > > correlation among sets of Flow Records/Packets Records. These sets > > can be Flow Records gathered during a certain period, a pair of > > consecutive Packet Reports, or Packet Reports exported by different > > Exporters indicating the same packet. After offering new metrics, > > the function outputs Flow Records with the new metrics field. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 14] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Applicable examples are as follows. > > > > o One way delay follows from correlating Packet Reports exported > > from different Exporters on the path. > > > > o Packet interval time, or jitter, follows from correlating > > consecutive Packet Reports exported from the same Exporter. > > > > o Difference values follow from correlating Flow Records observed at > > ingress or egress interfaces. The values help to confirm the > > result of a queueing or rate-limiting function. > > > > o Average/maximum/minimum values follow from correlating each in a > > set of Flow Records. > > > > 4.3.5. Modification Function > > > > > > The Modification function modifies input Flow Records/Packet Reports > > without changing their granularity. The function can add new > > Information Elements, delete existing Information Elements, or modify > > the value of specified Information Elements. If the function > > modifies the data structure of an original Template, it also needs to > > modify the value of the "flowKeyIndicator". > > > > Adding specified Information Elements > > > > The function obtains the value of a specified Information Element > > and then adds it into Flow Records/Packet Reports. There are > > several methods to obtain the value: retrieving the value from a > > database or calculating the value based on the value of other > > Information Elements and received traffic data. > > > > Applicable examples include adding derived packet property > > parameters instead of Original Exporters. Doing that can > > remove "instead of Original Exporters" > > > compensate for traditional Exporters or probes unable to add > > packet property parameters. Therefore, Collectors do not need to > > recognize the difference among implementations of routers from > > several vendors or among Exporter types, such as router, switch, > > or probe. Typical derived packet property parameters include the > > following. > > > > * The "bgpNextHop{IPv4|IPv6}Address" described in [RFC5102] > > indicates the egress router of a network domain. That is > > useful for making a traffic matrix that covers the whole > > network domain. > > > > * The BGP Community value indicates the same group of destination > > or source IP addresses. > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 15] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > * The "mplsVpnRouteDistinguisher" described in [RFC5102], which > > cannot be extracted from the core router in MPLS networks, > > indicates the VPN customer's identification. Network operators > > can monitor the traffic behavior of each customer by adding > > "mplsVpnRouteDistinguisher" to Flow Records/Packet Reports. > > > > Deleting specified Information Elements > > > > This function deletes existing Information Elements according to > > instruction rules, which indicate whether an Information Element > > should be removed. > > > > Applicable examples include hiding network topology information > > and private information. In the case of IPFIX exporting across > > domains, the function can avoid making a vulnerability by deleting > > unnecessary Information Elements. Examples of network topology > > information include "ipNextHopIP{v4|v6}Address", "bgpNextHopIP{v4| > > v6}Address", and "bgp{Next|Prev}AdjacentAsNumber", described in > > [RFC5102]. In addition, MPLS-related Information Elements, such > > as "mplsLabelStackSection", are useless for customers in the case > > of feeding Flow Records/Packet Reports to VPN customers. > > > > Modifying the value of specified Information Elements > > > > This function modifies the value of specified Information > > Elements. > > > > Applicable examples include anonymizing customers' private > > information, such as IP address and port number, according to a > > privacy protection policy. Several annonymization techniques are > > described in [I-D.boschi-ipfix-anon]. The function also reports > > anonymization methods and part of anonymized data as subsidiary > > information. > > > > 4.4. IPFIX File Writer/Reader > > > > > > The IPFIX File Writer stores input Flow Records/Packet Reports from > > any process in a storage system. If received Flow Records/Packet > > It's a "file system". > > > Reports include uninteresting Information Elements, the Modification > > Function can delete these elements before the IPFIX File Writer > > handles them. Therefore, IPFIX File Writers can accept input from > > any process. In either case, input needs to include the IPFIX header > > Remove the whole sentence "Therefore,..." > > > information and the Transport Session Information along with Flow > > Records/Packet Reports. > > Why does the File Writer require header information and transport > session information as input? > We should not specify additional restrictions for the File Writer here. > Also, there are cases where there are no headers and no transport > sessions, e.g. if the writer is linked to a Metering Process. > OK. But, if I'm not mistaken, I think that IPFIX file format includes session information and Observation Domain ID. I don't intend to add other restrictions for the File Writer. I will read more IPFIX file format draft. > > > > In contrast, the IPFIX File Reader retrieves stored Flow Records/ > > Packet Reports when operators want to retrieve past Flow Records/ > > Packet Reports on the basis of a given time period. If the data > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 16] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > structure of output Flow Records/Packet Reports from the IPFIX File > > Reader is different from what operators want, the Modification > > function can modify the data structure. Therefore, the output of > > IPFIX File Readers can be input to any components. The IPFIX File > > Writer/Reader are described in [I-D.ietf-ipfix-file] in detail. > > > > The figure shows the IPFIX component model with IPFIX File Writer/ > > Reader. IPFIX File Writer/Reader are located in the same position of > > Exporting Process/Collecting Process, respectively. > > According to ipfix-file, IPFIX File Writer/Reader operate as EP/CP. So, > "located in the same position of EP/CP" is not precise language because > writer/reader are specific types of EPs and CPs. > OK. > > > > IPFIX (Flow Records/Packet Reports) > > ^ > > ^ | > > .----------------------|-+--------------------. > > .-----------------------+---------------------.| > > | Exporting Process (es) / IPFIX File Writer |' > > '----^------------------^---------------------' > > | | | > > | .-------------|-+--------------------. > > | .--------------+---------------------.| > > | | Intermediate Process (es) |' > > | '--------------^-^-------------------' > > | | | > > .---+------------------|-+--------------------. > > .-----------------------+---------------------.| > > | Collecting Process (es) / IPFIX File Reader |' > > '-----------------------^---------------------' > > | > > IPFIX (Flow Records/Packet Reports) > > > > > > Figure E: IPFIX Mediator Component Model with IPFIX File Writer/ > > Reader. > > > > 4.5. Flow Expiration > > > > > > The Aggregation function needs expiration conditions to export cached > > Flow Records. These conditions are described in > > [I-D.ietf-ipfix-architecture]. In the case of IPFIX Mediation, these > > conditions are as follows: > > > > o If there are no input/received Flow Records/Packet Reports > > belonging to a cached Flow for a certain time period, aggregated > > Flow Records will expire. This time period should be configurable > > at the Intermediate Process. > > > > o If the IPFIX Mediator experiences resource constraints, aggregated > > Flow Records may prematurely expire (e.g., lack of memory to store > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 17] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Flow Records). > > > > o For long-running Flows, the Intermediate Process should expire the > > Flow on a regular basis or based on some expiration policy. This > > periodicity or expiration policy should be configurable at the > > Intermediate Process. > > > > The Correlation function also needs similar expiration conditions. > > However, when cached Flow Records/Packet Reports prematurely expire > > and the function can not compute the correlation among them, cached > > Flow Records/Packet reports may be discarded. > > > > 4.6. Information Model > > > > > > IPFIX Mediation reuse the general information model from [RFC5101] > > and from [I-D.ietf-psamp-info]. The following new Information > > Elements for IPFIX Mediation are also needed. > > > > +-----+---------------------------+-----+---------------------------+ > > | ID | Name | ID | Name | > > +-----+---------------------------+-----+---------------------------+ > > | XXX | averageBitRate | XXX | averagePacketsRate | > > | XXX | minimumBitRate | XXX | minimumPacketsRate | > > | XXX | maximumBitRate | XXX | maximumPacketsRate | > > +-----+---------------------------+-----+---------------------------+ > > I'm not sure if we should start exporting "rate" IEs. Rates do not > represent stable metrics. It's always better to measure "counts". So, I > suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. > Certainly, yes. If proposing "maximumPacketDeltaCount", we also need to propose other Information Element that shows time period of original Flow Records. Because the start time and end time of Flow Record are changed in Mediator. Collector can not recognize the delta time. What do yo think? > I do not understand why average rate is needed. You easily get the > average rate by dividing the delta count of the entire measurement > interval by the interval length. > Actually, Yes. But, this subsection is pointed out yesterday at IPFIX meeting. The definition of Information Elements should not be described in framework draft as Informational. Therefore, I will write down more conceptional idea only. > > > > 4.7. Examples > > > > > > As example, in case of Intermediate Processes having different > > functions, a Collecting Process/IPFIX File Reader replicates Flow > > Records/Packet Reports, if necessary, and forwards them to a suitable > > Intermediate Process/Exporting Process. Example figure is shown > > below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 18] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > IPFIX IPFIX IPFIX > > ^ ^ ^ > > | | | > > .------------. .-----+-------. .-----+-------. .------+------. > > | IPFIX File | | Exporting | | Exporting | | Exporting | > > | Writer | | Process {i}| | Process {j}|....| Process {n}| > > '-----^-^----' '-----^-------' '-----^-------' '------^------' > > | | | | | > > | +-------------+ | Flow Records > > | Flow Records / Packet Reports | > > | .------+-------. .-----+--------. .------+-------. > > | | Intermediate | | Intermediate | | Intermediate | > > | | Process {l} | | Process {m} | | Process {p} | > > | | | | |...| | > > | | Flow-based | | Flow-based | | | > > | | Collector | | Collector | | | > > | | Selection | | Selection | | | > > Flow Records | ^ | | ^ | | | > > | | | | | | | | | > > | | Correlation | | Modification| | Modification| > > | | ^ | | ^ | | ^ | > > | | | | | | | | | | > > | | Selection | | Aggregation |...| Selection | > > | | ^ | | ^ ^ | | ^ | > > | '------|-------' '-----|-|------' '------|-------' > > | | | | | > > | +---------------+ | Flow Records > > | | | | > > | Flow Records / Packet Reports | > > .------+------. .------+------. .------+------. .-----+------. > > | Collecting | | Collecting | | Collecting | | IPFIX File | > > | Process {i}| | Process {j}|...| Process {n}| | Reader | > > '------^------' '------^------' '------^------' '------------' > > | | | > > IPFIX IPFIX IPFIX > > > > Figure F: Functional Block Examples for IPFIX Mediator. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 19] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 5. Security Considerations > > > > > > IPFIX Mediators use the IPFIX protocol. Security considerations > > about Flow Records are described in [RFC5101]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 20] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 6. IANA Considerations > > > > > > This document has no actions for IANA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 21] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > 7. References > > > > > > 7.1. Normative References > > > > > > [I-D.ietf-ipfix-architecture] > > Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, > > "Architecture for IP Flow Information Export", > > draft-ietf-I-D.ietf-ipfix-architectureitecture-12.txt(work > > in progress) , September 2006. > > > > [I-D.ietf-psamp-framework] > > Duffield, N., "A Framework for Packet Selection and > > Reporting", draft-ietf-psamp-framework-13.txt , June 2008. > > > > [I-D.ietf-psamp-info] > > Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. > > Carle, "Information Model for Packet Sampling Exports", > > draft-ietf-psamp-info-11.txt (work in progress) , > > October 2008. > > > > [I-D.ietf-psamp-protocol] > > Claise, B., Quittek, J., and A. Johnson, "Packet Sampling > > (PSAMP) Protocol Specifications", > > draft-ietf-psamp-protocol-09.txt , December 2007. > > > > [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, > > "Requirements for IP Flow Information Export(IPFIX)", > > October 2004. > > > > [RFC5101] Claise, B., "Specification of the IP Flow Information > > Export (IPFIX) Protocol for the Exchange of IP Traffic > > Flow Information", January 2008. > > > > [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. > > Meyer, "Information Model for IP Flow Information Export", > > January 2008. > > > > 7.2. Informative References > > > > > > [I-D.boschi-ipfix-anon] > > Boschi, E. and B. Trammell, "IP Flow Anonymisation > > Support", draft-boschi-ipfix-anon-01.txt (work in > > progress) , July 2008. > > > > [I-D.dressler-ipfix-aggregation] > > Dressler, F., Sommer, C., Munz, G., and A. Kobayashi, > > "IPFIX Aggregation", > > draft-dressler-ipfix-aggregation-05.txt (work in > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 22] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > progress) , July 2008. > > > > [I-D.ietf-ipfix-file] > > Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. > > Wagner, "An IPFIX-Based File Format", > > draft-ietf-ipfix-file-03.txt(work in progress) , > > October 2008. > > > > [I-D.ietf-ipfix-mediator-ps] > > Kobayashi, A., Nishida, H., Sommer, C., Dressler, F., > > Stephan, E., and B. Claise, "IPFIX Mediation: Problem > > Statement", > > draft-ietf-ipfix-mediation-problem-statement-01.txt(work > > in progress) , September 2008. > > > > [I-D.peluso-flowselection] > > Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow > > selection Techniques", > > draft-peluso-flowselection-tech-01.txt(work in progress) , > > November 2007. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 23] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Appendix A. Acknowledgements > > > > > > The authors gratefully acknowledge the contributions of > > > > Keisuke Ishibashi, > > Tsuyoshi Kondoh, and > > Daisuke Matsubara. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 24] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Authors' Addresses > > > > Atsushi Kobayashi > > NTT Information Sharing Platform Laboratories > > 3-9-11 Midori-cho > > Musashino-shi, Tokyo 180-8585 > > Japan > > > > Phone: +81-422-59-3978 > > Email: akoba@nttv6.net > > > > > > Haruhiko Nishida > > NTT Information Sharing Platform Laboratories > > 3-9-11 Midori-cho > > Musashino-shi, Tokyo 180-8585 > > Japan > > > > Phone: +81-422-59-3978 > > Email: nishida.haruhiko@lab.ntt.co.jp > > > > > > Benoit Claise > > Cisco Systems > > De Kleetlaan 6a b1 > > Diegem 1831 > > Belgium > > > > Phone: +32 2 704 5622 > > Email: bclaise@cisco.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 25] > > > > > > Internet-Draft IPFIX Mediation Framework November 2008 > > > > > > Full Copyright Statement > > > > Copyright (C) The IETF Trust (2008). > > > > This document is subject to the rights, licenses and restrictions > > contained in BCP 78, and except as set forth therein, the authors > > retain all their rights. > > > > This document and the information contained herein are provided on an > > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS > > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF > > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > Intellectual Property > > > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might be claimed to > > pertain to the implementation or use of the technology described in > > this document or the extent to which any license under such rights > > might or might not be available; nor does it represent that it has > > made any independent effort to identify any such rights. Information > > on the procedures with respect to rights in RFC documents can be > > found in BCP 78 and BCP 79. > > > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the use of > > such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR repository at > > http://www.ietf.org/ipr. > > > > The IETF invites any interested party to bring to its attention any > > copyrights, patents or patent applications, or other proprietary > > rights that may cover technology that may be required to implement > > this standard. Please address the information to the IETF at > > ietf-ipr@ietf.org. > > > > > > > > > > > > > > > > > > > > > > > > Kobayashi, et al. Expires May 8, 2009 [Page 26] -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 13:12:32 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411628C261; Thu, 20 Nov 2008 13:12:32 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618A728C24E; Thu, 20 Nov 2008 13:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, SARE_SUB_10CONS_WORD=0.639, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUABPnCNSQz; Thu, 20 Nov 2008 13:12:30 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D3D2B28C24D; Thu, 20 Nov 2008 13:12:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCSB14192; Thu, 20 Nov 2008 22:12:28 +0100 (CET) Received: from [10.61.88.43] (ams3-vpn-dhcp6188.cisco.com [10.61.88.43]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCDG14067; Thu, 20 Nov 2008 22:12:13 +0100 (CET) Message-ID: <4925D2AD.8060304@cisco.com> Date: Thu, 20 Nov 2008 15:12:13 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: tsvwg@ietf.org Cc: "ipfix@ietf.org" Subject: [IPFIX] Reference to draft-stewart-tsvwg-sctpstrrst-00.txt in our IPFIX document X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736483188==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0736483188== Content-Type: multipart/alternative; boundary="------------080403000607020403050406" This is a multi-part message in MIME format. --------------080403000607020403050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, With this email, we want to stress to importance of draft-stewart-tsvwg-sctpstrrst-00.txt for the IP Flow Information eXport (IPFIX) WG. As you might know, the IFPIX protocol RFC5101 runs on the top of PR-SCTP. We have developed a new draft: "IPFIX Export per SCTP Stream", http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-01 Abstract This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101 . This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. In a nutshell, this draft specifies that we should export a Template Record and its associated Flow Records within a single stream so that we could deduce the loss per Template. Indeed, if multiple Tempate Records and associated Flow Records are sent within a single stream and one IPFIX Message is lost, we don't know to which Template we should assign the loss. If we increase the number of Template Record during the live time of the IPFIX Device, we should increase the number of streams. Obviously, shutting down the association to increase the number of streams is not an option ;-) So the feature we need from draft-stewart-tsvwg-sctpstrrst-00.txt is the addition of streams in an existing SCTP association. The draft "IPFIX Export per SCTP Stream" passed the WGLC is a ready for the write-up but the normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt blocks us. Dan Romascanu, our OPS AD, suggested to describe a brief summary of the mechanism in our IPFIX draft, then to move the draft-stewart-tsvwg-sctpstrrst-00.txt reference from normative to informative. That trick would help with our draft in the short term, even to produce a RFC. However, the longer term goal would be to have a RFC specifying the stream addition in an existing SCTP association. Once done, it can be used as a normative reference. Feedback? Regards, Benoit. --------------080403000607020403050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

With this email, we want to stress to importance of  draft-stewart-tsvwg-sctpstrrst-00.txt for the IP Flow Information eXport (IPFIX) WG.

As you might know, the IFPIX protocol RFC5101 runs on the top of PR-SCTP.
We have developed a new draft: "IPFIX Export per SCTP Stream", http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-01
     Abstract
     
        This document specifies an improvement to the PR-SCTP
        export specified in the IPFIX specifications in RFC5101.
        This method offers several advantages such as the ability to
        calculate Data Record losses for PR-SCTP, immediate export of
        Template Withdrawal Messages, immediate reuse of Template IDs
        within an SCTP stream, and reduced demands on the Collecting
        Process.
In a nutshell, this draft specifies that we should export a Template Record and its associated Flow Records within a single stream so that we could deduce the loss per Template. Indeed, if multiple Tempate Records and associated  Flow Records are sent within a single stream and one IPFIX Message is lost, we don't know to which Template we should assign the loss. If we increase the number of Template Record during the live time of the IPFIX Device, we should increase the number of streams. Obviously, shutting down the association to increase the number of streams is not an option ;-)
So the feature we need from draft-stewart-tsvwg-sctpstrrst-00.txt is the addition of streams in an existing SCTP association.

The draft "IPFIX Export per SCTP Stream" passed the WGLC is a ready for the write-up but the normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt blocks us.  Dan Romascanu, our OPS AD, suggested to describe a brief summary of the mechanism in our IPFIX draft, then to move the draft-stewart-tsvwg-sctpstrrst-00.txt reference from normative to informative.
That trick would help with our draft in the short term, even to produce a RFC. However, the longer term goal would be to have a RFC specifying the stream addition in an existing SCTP association. Once done,  it can be used as a normative reference.

Feedback?

Regards, Benoit.


--------------080403000607020403050406-- --===============0736483188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0736483188==-- From ipfix-bounces@ietf.org Thu Nov 20 13:12:32 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411628C261; Thu, 20 Nov 2008 13:12:32 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618A728C24E; Thu, 20 Nov 2008 13:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.926 X-Spam-Level: X-Spam-Status: No, score=-0.926 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, SARE_SUB_10CONS_WORD=0.639, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaUABPnCNSQz; Thu, 20 Nov 2008 13:12:30 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id D3D2B28C24D; Thu, 20 Nov 2008 13:12:29 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCSB14192; Thu, 20 Nov 2008 22:12:28 +0100 (CET) Received: from [10.61.88.43] (ams3-vpn-dhcp6188.cisco.com [10.61.88.43]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAKLCDG14067; Thu, 20 Nov 2008 22:12:13 +0100 (CET) Message-ID: <4925D2AD.8060304@cisco.com> Date: Thu, 20 Nov 2008 15:12:13 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: tsvwg@ietf.org Cc: "ipfix@ietf.org" Subject: [IPFIX] Reference to draft-stewart-tsvwg-sctpstrrst-00.txt in our IPFIX document X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0736483188==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0736483188== Content-Type: multipart/alternative; boundary="------------080403000607020403050406" This is a multi-part message in MIME format. --------------080403000607020403050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, With this email, we want to stress to importance of draft-stewart-tsvwg-sctpstrrst-00.txt for the IP Flow Information eXport (IPFIX) WG. As you might know, the IFPIX protocol RFC5101 runs on the top of PR-SCTP. We have developed a new draft: "IPFIX Export per SCTP Stream", http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-01 Abstract This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101 . This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. In a nutshell, this draft specifies that we should export a Template Record and its associated Flow Records within a single stream so that we could deduce the loss per Template. Indeed, if multiple Tempate Records and associated Flow Records are sent within a single stream and one IPFIX Message is lost, we don't know to which Template we should assign the loss. If we increase the number of Template Record during the live time of the IPFIX Device, we should increase the number of streams. Obviously, shutting down the association to increase the number of streams is not an option ;-) So the feature we need from draft-stewart-tsvwg-sctpstrrst-00.txt is the addition of streams in an existing SCTP association. The draft "IPFIX Export per SCTP Stream" passed the WGLC is a ready for the write-up but the normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt blocks us. Dan Romascanu, our OPS AD, suggested to describe a brief summary of the mechanism in our IPFIX draft, then to move the draft-stewart-tsvwg-sctpstrrst-00.txt reference from normative to informative. That trick would help with our draft in the short term, even to produce a RFC. However, the longer term goal would be to have a RFC specifying the stream addition in an existing SCTP association. Once done, it can be used as a normative reference. Feedback? Regards, Benoit. --------------080403000607020403050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

With this email, we want to stress to importance of  draft-stewart-tsvwg-sctpstrrst-00.txt for the IP Flow Information eXport (IPFIX) WG.

As you might know, the IFPIX protocol RFC5101 runs on the top of PR-SCTP.
We have developed a new draft: "IPFIX Export per SCTP Stream", http://tools.ietf.org/html/draft-ietf-ipfix-export-per-sctp-stream-01
     Abstract
     
        This document specifies an improvement to the PR-SCTP
        export specified in the IPFIX specifications in RFC5101.
        This method offers several advantages such as the ability to
        calculate Data Record losses for PR-SCTP, immediate export of
        Template Withdrawal Messages, immediate reuse of Template IDs
        within an SCTP stream, and reduced demands on the Collecting
        Process.
In a nutshell, this draft specifies that we should export a Template Record and its associated Flow Records within a single stream so that we could deduce the loss per Template. Indeed, if multiple Tempate Records and associated  Flow Records are sent within a single stream and one IPFIX Message is lost, we don't know to which Template we should assign the loss. If we increase the number of Template Record during the live time of the IPFIX Device, we should increase the number of streams. Obviously, shutting down the association to increase the number of streams is not an option ;-)
So the feature we need from draft-stewart-tsvwg-sctpstrrst-00.txt is the addition of streams in an existing SCTP association.

The draft "IPFIX Export per SCTP Stream" passed the WGLC is a ready for the write-up but the normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt blocks us.  Dan Romascanu, our OPS AD, suggested to describe a brief summary of the mechanism in our IPFIX draft, then to move the draft-stewart-tsvwg-sctpstrrst-00.txt reference from normative to informative.
That trick would help with our draft in the short term, even to produce a RFC. However, the longer term goal would be to have a RFC specifying the stream addition in an existing SCTP association. Once done,  it can be used as a normative reference.

Feedback?

Regards, Benoit.


--------------080403000607020403050406-- --===============0736483188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0736483188==-- From ipfix-bounces@ietf.org Thu Nov 20 13:58:35 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0693A68C5; Thu, 20 Nov 2008 13:58:35 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EB73A68C5 for ; Thu, 20 Nov 2008 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQib5OCLQ7qQ for ; Thu, 20 Nov 2008 13:58:34 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id B5C233A677D for ; Thu, 20 Nov 2008 13:58:33 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 234F9474AA; Thu, 20 Nov 2008 22:58:23 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id AD2BF90F; Thu, 20 Nov 2008 22:58:22 +0100 (CET) Message-ID: <4925DD8A.6070306@net.in.tum.de> Date: Thu, 20 Nov 2008 22:58:34 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4921700B.1040602@net.in.tum.de> <20081121050251.0A57.17391CF2@nttv6.net> In-Reply-To: <20081121050251.0A57.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0283686497==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0283686497== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010400070208020800080700" This is a cryptographically signed message in MIME format. --------------ms010400070208020800080700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Atsushi, Some answers inline. Regards, Gerhard Atsushi Kobayashi wrote: >>> Mediator Observation Domain >>> >>> An IPFIX Mediator does not host the Observation Points and >> Why should we disallow IPFIX Mediators which also have native >> Observation Points? >> >>> Observation Domain. The Observation Domain ID in the IPFIX hea= der >>> sent by the IPFIX Mediator also indicates the largest set of >>> Observation Points from the viewpoint of a Collector. However,= >> This seems to be too generic. The ODID issued by the mediator should >> identify the set of ODs/OPs the exported records belong to. >=20 > Yes. >=20 >> It does not always have to be the "largest set of OPs", it can be a su= bset. >> > Certainly, yes. >=20 >> As an example, the Mediator may be configured not to merge records fro= m >> different OPs at all. In this case, we can keep the old OIDs. Or it ma= y >> be configured to merge records from a specific subset of OPs only. >> > Based on your comments, I think that term "Mediator Observation Domain"= > is unnecessary. Because term "Observation Domain" can be applied to > IPFIX Mediator as well, and the meaning is not changed. >=20 > Is it better to remove this term? Not sure. RFC 5101 says: Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. ... Observation Domain ID ... The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported. The last sentence already covers the problem of aggregation. If you are happy with ODID=3D0 for Mediators, then you do not have to introduce "Mediator Observation Domain". If you want to use other values, maybe it is necessary to introduce a new term here. >=20 >>> this value does not indicate the physical entity of an Original= >>> Exporter. >>> 3. IPFIX Mediation Reference Model >>> >>> >>> The figure below shows the high-level reference model for IPFIX >>> Mediation based on [I-D.ietf-ipfix-architecture]. This figure cov= ers >>> the various possible scenarios that can exist in an IPFIX measurem= ent >>> system. >>> >>> >>> +---------------------------+ +---------------------------+ >>> | Collector {l} | | Collector {k} | >>> |[*Application(s)] | |[*Application(s)] | >>> |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | >>> |[Collecting Process(es)] |....|[Collecting Process(es)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ ^ >>> | | | | >>> | +------....----+ | >>> | | | >>> IPFIX (Flow Records / Packet Reports) >>> | | | >>> +----------------+----+-----+ +-------+-------------------+ >>> |IPFIX Mediator {j} | |IPFIX Mediator {n} | >>> |[*Applications(s)] | |[*Applications(s)] | >>> |[Exporting Process(es)] | |[Exporting Process(es)] | >>> |[Intermediate Process(es)] |....|[Intermediate Process(es)] | >>> |[Collecting Process(es)] | |[Collecting Process(es)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ >>> | | | >>> | +------....-----+ >>> | | >>> IPFIX (Flow Records / Packet Reports) >>> | | >>> +----------------+----------+ +----+----------------------+ >>> |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| >>> |[Exporting Process(es)] | |[Exporting Process(es)] | >>> |[Metering Process(es)] |....|[Metering Process(es)] | >>> |[Observation Point(s)] | |[Observation Point(s)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ ^ >>> | | | | >>> Packets coming in to Observation Points >>> >>> Figure A: Reference Model for IPFIX Mediation. >>> >>> The various functional components are indicated within brackets []= =2E >>> The functional components within [*] are not part of >>> [I-D.ietf-ipfix-architecture]. >> Hm. Intermediate Process as well as IPFIX reader/writer are not part o= f >> ipfix-architecture either. >> >=20 > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it= > make sense? Ok. You could also remove the Applications from the figure. >>> 4.3. Intermediate Process >>> >>> >>> Intermediate Processes generate new sets of Flow Records/Packet >>> Reports from input Flow Records/Packet Reports with IPFIX header >>> information "Export Time" and "Observation Domain ID". The proces= ses >> I would not call it "IPFIX header information" because there are no >> IPFIX Messages at the input of the Intermediate Process, only Records.= >> Maybe "context information collected at the Collecting Process"? >> >=20 > I will improve as follows. >=20 > Intermediate Processes generate new sets of Flow Records/Packet > Reports from input Flow Records/Packet Reports with context information= > collected at the Collecting Process that includes "Export Time" and > "Observation Domain ID". >=20 > Is it OK? Yes, that sounds good. >>> 4.3.2. Flow-based Collector Selection Function >>> >>> >>> The Flow-based Collector Selection function determines to which >>> Collector input Flow Records/Packet Reports are exported. The >>> function may also determine the type of Transport Session. The >> This functional description conflicts with the Exporting Process. In m= y >> opinion, the Exporting Process holds the information about the >> Collectors, transport protocol etc. >> >>> function evaluates the value of a specified Information Element in= >>> input Flow Records/Packet Reports and then selects the Collector. >> So, what is the difference between Flow-Based Colelctor Selection >> Function and Flow Selection Function plus Exporting Process? >> >> I'm not sure if Flow-based Collector Selection should be a function of= >> its own. I would rather say that it describes a use-case of one or >> multiple Flow Selection Functions and Exporting Processes: >> >> +--> Flow Selector 1 -> EP 1 >> ----+ >> +--> Flow Selector 2 -> EP 2 >> >> >=20 > Actually, I have been wondering in which Flow-based Collector Selection= > function should be located in, Metering Process or Exporting Process. You mean: in the Intermediate Process or Exporting Process? > And also, Flow-based Collector Selection function is special case of > Selection function. Term "Flow-based Collector Selection" seems to be > unnecessary. >=20 > Your opinion is reasonable. I will try to write down your idea. >=20 >>> Space Composition >>> >>> Space composition is defined as aggregation on a larger >>> Observation Domain or on a set of Observation Points. In that >>> case, a Flow key can be applied to other properties, such as >> What do you mean by "a Flow Key can be applied to "? >> >=20 > Maybe, it is English issue. >=20 > Generally, Flow Key fields are included in Flow Records. But, in that > case, other properties that are not included in Flow Records, such as > Exporter IP address or Observation Domain ID, become Flow Key fields. >=20 > Is it OK? Yes, that's better. >>> 4.4. IPFIX File Writer/Reader >>> >>> >>> The IPFIX File Writer stores input Flow Records/Packet Reports fro= m >>> any process in a storage system. If received Flow Records/Packet >> It's a "file system". >> >>> Reports include uninteresting Information Elements, the Modificati= on >>> Function can delete these elements before the IPFIX File Writer >>> handles them. Therefore, IPFIX File Writers can accept input from= >>> any process. In either case, input needs to include the IPFIX hea= der >> Remove the whole sentence "Therefore,..." >> >>> information and the Transport Session Information along with Flow >>> Records/Packet Reports. >> Why does the File Writer require header information and transport >> session information as input? >> We should not specify additional restrictions for the File Writer here= =2E >> Also, there are cases where there are no headers and no transport >> sessions, e.g. if the writer is linked to a Metering Process. >> >=20 > OK. But, if I'm not mistaken, I think that IPFIX file format includes > session information and Observation Domain ID. One IPFIX file corresponds to one transport session. So, there is no further information required. The ODID is included in the Message headers as usual. > I don't intend to add other restrictions for the File Writer. >=20 > I will read more IPFIX file format draft.=20 >>> 4.6. Information Model >>> >>> >>> IPFIX Mediation reuse the general information model from [RFC5101]= >>> and from [I-D.ietf-psamp-info]. The following new Information >>> Elements for IPFIX Mediation are also needed. >>> >>> +-----+---------------------------+-----+-------------------------= --+ >>> | ID | Name | ID | Name = | >>> +-----+---------------------------+-----+-------------------------= --+ >>> | XXX | averageBitRate | XXX | averagePacketsRate = | >>> | XXX | minimumBitRate | XXX | minimumPacketsRate = | >>> | XXX | maximumBitRate | XXX | maximumPacketsRate = | >>> +-----+---------------------------+-----+-------------------------= --+ >> I'm not sure if we should start exporting "rate" IEs. Rates do not >> represent stable metrics. It's always better to measure "counts". So, = I >> suggest to have maximumPacketDeltaCount instead of maximumPacketsRate = etc. >> > Certainly, yes. >=20 > If proposing "maximumPacketDeltaCount", we also need to propose other > Information Element that shows time period of original Flow Records. Yes, of course. > Because the start time and end time of Flow Record are changed in > Mediator. Collector can not recognize the delta time. >=20 > What do yo think? >=20 >> I do not understand why average rate is needed. You easily get the >> average rate by dividing the delta count of the entire measurement >> interval by the interval length. >> > Actually, Yes. >=20 > But, this subsection is pointed out yesterday at IPFIX meeting. > The definition of Information Elements should not be described in > framework draft as Informational. >=20 > Therefore, I will write down more conceptional idea only. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010400070208020800080700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyMDIxNTgzNFowIwYJKoZIhvcNAQkEMRYEFMJcT7pMYxhq oBs7hcZQJ1GfQdIcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAt/egNjenCBW/LZOISz2KFg2bpUJaOdyPP1gbGh97NfSSXPn48JLOzCUYq q6Dn/5ZnSKUWMmdtt9SyEYhdt7bC0Z724ztcj6RXykzoN8tI3b4lnSRVnnaWY3qtu1kk+qRb 9f/Ke/JIbAbiSQqY1zX1tvMSHj+kgbWMRncBHKLW6bjjJQiMDlONY+DFBT+WNF3vXw383eoh qQOUr86fHsc8xzT0f/VKodOyeZTYwgKjzcnULdPme7//QaIB2xEQ5NiKOPgoisnOwpSRWST+ 3lwPF++uDwAbnXPrRIkyd7fAEXjhzA49JcdOlYOTVu7aDBIinZOJyG4yn5UApz2DVJaKAAAA AAAA --------------ms010400070208020800080700-- --===============0283686497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0283686497==-- From ipfix-bounces@ietf.org Thu Nov 20 13:58:35 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0693A68C5; Thu, 20 Nov 2008 13:58:35 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EB73A68C5 for ; Thu, 20 Nov 2008 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQib5OCLQ7qQ for ; Thu, 20 Nov 2008 13:58:34 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id B5C233A677D for ; Thu, 20 Nov 2008 13:58:33 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 234F9474AA; Thu, 20 Nov 2008 22:58:23 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id AD2BF90F; Thu, 20 Nov 2008 22:58:22 +0100 (CET) Message-ID: <4925DD8A.6070306@net.in.tum.de> Date: Thu, 20 Nov 2008 22:58:34 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4921700B.1040602@net.in.tum.de> <20081121050251.0A57.17391CF2@nttv6.net> In-Reply-To: <20081121050251.0A57.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0283686497==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0283686497== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010400070208020800080700" This is a cryptographically signed message in MIME format. --------------ms010400070208020800080700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Atsushi, Some answers inline. Regards, Gerhard Atsushi Kobayashi wrote: >>> Mediator Observation Domain >>> >>> An IPFIX Mediator does not host the Observation Points and >> Why should we disallow IPFIX Mediators which also have native >> Observation Points? >> >>> Observation Domain. The Observation Domain ID in the IPFIX hea= der >>> sent by the IPFIX Mediator also indicates the largest set of >>> Observation Points from the viewpoint of a Collector. However,= >> This seems to be too generic. The ODID issued by the mediator should >> identify the set of ODs/OPs the exported records belong to. >=20 > Yes. >=20 >> It does not always have to be the "largest set of OPs", it can be a su= bset. >> > Certainly, yes. >=20 >> As an example, the Mediator may be configured not to merge records fro= m >> different OPs at all. In this case, we can keep the old OIDs. Or it ma= y >> be configured to merge records from a specific subset of OPs only. >> > Based on your comments, I think that term "Mediator Observation Domain"= > is unnecessary. Because term "Observation Domain" can be applied to > IPFIX Mediator as well, and the meaning is not changed. >=20 > Is it better to remove this term? Not sure. RFC 5101 says: Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. ... Observation Domain ID ... The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported. The last sentence already covers the problem of aggregation. If you are happy with ODID=3D0 for Mediators, then you do not have to introduce "Mediator Observation Domain". If you want to use other values, maybe it is necessary to introduce a new term here. >=20 >>> this value does not indicate the physical entity of an Original= >>> Exporter. >>> 3. IPFIX Mediation Reference Model >>> >>> >>> The figure below shows the high-level reference model for IPFIX >>> Mediation based on [I-D.ietf-ipfix-architecture]. This figure cov= ers >>> the various possible scenarios that can exist in an IPFIX measurem= ent >>> system. >>> >>> >>> +---------------------------+ +---------------------------+ >>> | Collector {l} | | Collector {k} | >>> |[*Application(s)] | |[*Application(s)] | >>> |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | >>> |[Collecting Process(es)] |....|[Collecting Process(es)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ ^ >>> | | | | >>> | +------....----+ | >>> | | | >>> IPFIX (Flow Records / Packet Reports) >>> | | | >>> +----------------+----+-----+ +-------+-------------------+ >>> |IPFIX Mediator {j} | |IPFIX Mediator {n} | >>> |[*Applications(s)] | |[*Applications(s)] | >>> |[Exporting Process(es)] | |[Exporting Process(es)] | >>> |[Intermediate Process(es)] |....|[Intermediate Process(es)] | >>> |[Collecting Process(es)] | |[Collecting Process(es)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ >>> | | | >>> | +------....-----+ >>> | | >>> IPFIX (Flow Records / Packet Reports) >>> | | >>> +----------------+----------+ +----+----------------------+ >>> |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| >>> |[Exporting Process(es)] | |[Exporting Process(es)] | >>> |[Metering Process(es)] |....|[Metering Process(es)] | >>> |[Observation Point(s)] | |[Observation Point(s)] | >>> +---------------------------+ +---------------------------+ >>> ^ ^ ^ ^ >>> | | | | >>> Packets coming in to Observation Points >>> >>> Figure A: Reference Model for IPFIX Mediation. >>> >>> The various functional components are indicated within brackets []= =2E >>> The functional components within [*] are not part of >>> [I-D.ietf-ipfix-architecture]. >> Hm. Intermediate Process as well as IPFIX reader/writer are not part o= f >> ipfix-architecture either. >> >=20 > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it= > make sense? Ok. You could also remove the Applications from the figure. >>> 4.3. Intermediate Process >>> >>> >>> Intermediate Processes generate new sets of Flow Records/Packet >>> Reports from input Flow Records/Packet Reports with IPFIX header >>> information "Export Time" and "Observation Domain ID". The proces= ses >> I would not call it "IPFIX header information" because there are no >> IPFIX Messages at the input of the Intermediate Process, only Records.= >> Maybe "context information collected at the Collecting Process"? >> >=20 > I will improve as follows. >=20 > Intermediate Processes generate new sets of Flow Records/Packet > Reports from input Flow Records/Packet Reports with context information= > collected at the Collecting Process that includes "Export Time" and > "Observation Domain ID". >=20 > Is it OK? Yes, that sounds good. >>> 4.3.2. Flow-based Collector Selection Function >>> >>> >>> The Flow-based Collector Selection function determines to which >>> Collector input Flow Records/Packet Reports are exported. The >>> function may also determine the type of Transport Session. The >> This functional description conflicts with the Exporting Process. In m= y >> opinion, the Exporting Process holds the information about the >> Collectors, transport protocol etc. >> >>> function evaluates the value of a specified Information Element in= >>> input Flow Records/Packet Reports and then selects the Collector. >> So, what is the difference between Flow-Based Colelctor Selection >> Function and Flow Selection Function plus Exporting Process? >> >> I'm not sure if Flow-based Collector Selection should be a function of= >> its own. I would rather say that it describes a use-case of one or >> multiple Flow Selection Functions and Exporting Processes: >> >> +--> Flow Selector 1 -> EP 1 >> ----+ >> +--> Flow Selector 2 -> EP 2 >> >> >=20 > Actually, I have been wondering in which Flow-based Collector Selection= > function should be located in, Metering Process or Exporting Process. You mean: in the Intermediate Process or Exporting Process? > And also, Flow-based Collector Selection function is special case of > Selection function. Term "Flow-based Collector Selection" seems to be > unnecessary. >=20 > Your opinion is reasonable. I will try to write down your idea. >=20 >>> Space Composition >>> >>> Space composition is defined as aggregation on a larger >>> Observation Domain or on a set of Observation Points. In that >>> case, a Flow key can be applied to other properties, such as >> What do you mean by "a Flow Key can be applied to "? >> >=20 > Maybe, it is English issue. >=20 > Generally, Flow Key fields are included in Flow Records. But, in that > case, other properties that are not included in Flow Records, such as > Exporter IP address or Observation Domain ID, become Flow Key fields. >=20 > Is it OK? Yes, that's better. >>> 4.4. IPFIX File Writer/Reader >>> >>> >>> The IPFIX File Writer stores input Flow Records/Packet Reports fro= m >>> any process in a storage system. If received Flow Records/Packet >> It's a "file system". >> >>> Reports include uninteresting Information Elements, the Modificati= on >>> Function can delete these elements before the IPFIX File Writer >>> handles them. Therefore, IPFIX File Writers can accept input from= >>> any process. In either case, input needs to include the IPFIX hea= der >> Remove the whole sentence "Therefore,..." >> >>> information and the Transport Session Information along with Flow >>> Records/Packet Reports. >> Why does the File Writer require header information and transport >> session information as input? >> We should not specify additional restrictions for the File Writer here= =2E >> Also, there are cases where there are no headers and no transport >> sessions, e.g. if the writer is linked to a Metering Process. >> >=20 > OK. But, if I'm not mistaken, I think that IPFIX file format includes > session information and Observation Domain ID. One IPFIX file corresponds to one transport session. So, there is no further information required. The ODID is included in the Message headers as usual. > I don't intend to add other restrictions for the File Writer. >=20 > I will read more IPFIX file format draft.=20 >>> 4.6. Information Model >>> >>> >>> IPFIX Mediation reuse the general information model from [RFC5101]= >>> and from [I-D.ietf-psamp-info]. The following new Information >>> Elements for IPFIX Mediation are also needed. >>> >>> +-----+---------------------------+-----+-------------------------= --+ >>> | ID | Name | ID | Name = | >>> +-----+---------------------------+-----+-------------------------= --+ >>> | XXX | averageBitRate | XXX | averagePacketsRate = | >>> | XXX | minimumBitRate | XXX | minimumPacketsRate = | >>> | XXX | maximumBitRate | XXX | maximumPacketsRate = | >>> +-----+---------------------------+-----+-------------------------= --+ >> I'm not sure if we should start exporting "rate" IEs. Rates do not >> represent stable metrics. It's always better to measure "counts". So, = I >> suggest to have maximumPacketDeltaCount instead of maximumPacketsRate = etc. >> > Certainly, yes. >=20 > If proposing "maximumPacketDeltaCount", we also need to propose other > Information Element that shows time period of original Flow Records. Yes, of course. > Because the start time and end time of Flow Record are changed in > Mediator. Collector can not recognize the delta time. >=20 > What do yo think? >=20 >> I do not understand why average rate is needed. You easily get the >> average rate by dividing the delta count of the entire measurement >> interval by the interval length. >> > Actually, Yes. >=20 > But, this subsection is pointed out yesterday at IPFIX meeting. > The definition of Information Elements should not be described in > framework draft as Informational. >=20 > Therefore, I will write down more conceptional idea only. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010400070208020800080700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyMDIxNTgzNFowIwYJKoZIhvcNAQkEMRYEFMJcT7pMYxhq oBs7hcZQJ1GfQdIcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQAt/egNjenCBW/LZOISz2KFg2bpUJaOdyPP1gbGh97NfSSXPn48JLOzCUYq q6Dn/5ZnSKUWMmdtt9SyEYhdt7bC0Z724ztcj6RXykzoN8tI3b4lnSRVnnaWY3qtu1kk+qRb 9f/Ke/JIbAbiSQqY1zX1tvMSHj+kgbWMRncBHKLW6bjjJQiMDlONY+DFBT+WNF3vXw383eoh qQOUr86fHsc8xzT0f/VKodOyeZTYwgKjzcnULdPme7//QaIB2xEQ5NiKOPgoisnOwpSRWST+ 3lwPF++uDwAbnXPrRIkyd7fAEXjhzA49JcdOlYOTVu7aDBIinZOJyG4yn5UApz2DVJaKAAAA AAAA --------------ms010400070208020800080700-- --===============0283686497== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0283686497==-- From ipfix-bounces@ietf.org Thu Nov 20 17:53:30 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEF03A68EC; Thu, 20 Nov 2008 17:53:30 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB703A68EC for ; Thu, 20 Nov 2008 17:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0C1ZE0sharY for ; Thu, 20 Nov 2008 17:53:28 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 71C383A689E for ; Thu, 20 Nov 2008 17:53:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 92D559DAAB for ; Fri, 21 Nov 2008 14:53:26 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dcwLk0D02dz for ; Fri, 21 Nov 2008 14:53:26 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C40ED9DAA9 for ; Fri, 21 Nov 2008 14:53:25 +1300 (NZDT) Message-ID: <49261494.2060206@auckland.ac.nz> Date: Fri, 21 Nov 2008 14:53:24 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] DRAFT IPFIX meeting minutes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Herewith draft minutes from Wednesday morning's meeting. Please send me any corrections. Cheers, Nevil Minutes of IPFIX Working Group session 0900, Wed 19 Nov 08 33 people attending + 6 more via jabber. IANA issues with the psamp-info draft were resolved Tuesday morning, it's now in the RFC Editor queue. That clears the 'normative reference needed state of the other three psamp drafts, and four ipfix drafts in the queue. Also, ongoing discussions with IANA over the ipfix Information Element registry are now complete; IANA have the IE Registry online, in XML. The IPFIX MIB was presented by Benoit Claise. It is now complete, Juergen will forward its writeup document to Dan. The psamp wg will now work on the psamp MIB (the last psamp document), and expect that to be finished fairly quickly. The psamp wg will then close. Brian Trammell presented the File Format draft. That draft, and the Exporting Types draft are now complete; Nevil will forward their writeup documents to Dan. Benoit presented the Per-SCTP-Stream draft. It is complete, but has a normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt, a tsvarea draft specifying SCTP Stream Resets. Since Per-Stream depends oFrom ipfix-bounces@ietf.org Thu Nov 20 17:53:30 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FEF03A68EC; Thu, 20 Nov 2008 17:53:30 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB703A68EC for ; Thu, 20 Nov 2008 17:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0C1ZE0sharY for ; Thu, 20 Nov 2008 17:53:28 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 71C383A689E for ; Thu, 20 Nov 2008 17:53:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 92D559DAAB for ; Fri, 21 Nov 2008 14:53:26 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dcwLk0D02dz for ; Fri, 21 Nov 2008 14:53:26 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id C40ED9DAA9 for ; Fri, 21 Nov 2008 14:53:25 +1300 (NZDT) Message-ID: <49261494.2060206@auckland.ac.nz> Date: Fri, 21 Nov 2008 14:53:24 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: IPFIX list Subject: [IPFIX] DRAFT IPFIX meeting minutes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi all: Herewith draft minutes from Wednesday morning's meeting. Please send me any corrections. Cheers, Nevil Minutes of IPFIX Working Group session 0900, Wed 19 Nov 08 33 people attending + 6 more via jabber. IANA issues with the psamp-info draft were resolved Tuesday morning, it's now in the RFC Editor queue. That clears the 'normative reference needed state of the other three psamp drafts, and four ipfix drafts in the queue. Also, ongoing discussions with IANA over the ipfix Information Element registry are now complete; IANA have the IE Registry online, in XML. The IPFIX MIB was presented by Benoit Claise. It is now complete, Juergen will forward its writeup document to Dan. The psamp wg will now work on the psamp MIB (the last psamp document), and expect that to be finished fairly quickly. The psamp wg will then close. Brian Trammell presented the File Format draft. That draft, and the Exporting Types draft are now complete; Nevil will forward their writeup documents to Dan. Benoit presented the Per-SCTP-Stream draft. It is complete, but has a normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt, a tsvarea draft specifying SCTP Stream Resets. Since Per-Stream depends on n that, Benoit will work with its author (Randall Stewart) to encourage tsvarea to accept it as a wg item and get it published as soon as possible. The Config Data Model draft was presented by Benoit. It is complete, but depends on having its actual data model written in YANG. YANG is not yet stable, the netconf wg expects to finish it by September 09. We agreed to keep the IPFIX Config Model draft as is, and wait for YANG to become stable. We will review that decision next year. Kobayashi Atsushi presented the two IPFIX Mediation drafts. These have both been updated following list discussion; that discussion continues, but both are nearing completion. Both of them reference three other drafts that had been discussed in the wg (flow anonymisation, aggregation, and flow selection techniques) as examples of IPFIX Mediation. We agreed that the drafts should be revised further to include brief summaries of the 'examples' drafts, and quite a few other issues that have arisen on the mailing list. We believe that those drafts will later reappear as wg work items for Mediation Intermediate Processes using the Mediation Framework. Nevil had circulated a proposed set of milestone changes on the list, they were discussed and amended. Under 'any other business,' it was reported that ippm have considered specifying some metrics derived from passive measurements - IPFIX would be a useful source of such data. Alt Morton commented that Passive Measurements have a low priority in ippm. Brian Trammel reported that he and Elisa Boschi had given an IPFIX tutorial at IMC. The meeting closed at 1020; thanks to Ralf Wolter for his meeting notes. ------------------------------------------------------------ One-para summary: The psamp-info draft is approved, all eight ipfix/psamp drafts can now appear as RFCs. IANA have published the IPFIX Information Elements Registry. Three IPFIX drafts are now complete, Nevil and Juergen will do their writeups and pass them to Dan. The SCTP-per-stream draft is waiting for a tsvarea document, SCTP Stream Reset. Our Config Model is complete, we're waiting to see how soon YANG will be stable. The two IPFIX Mediators drafts are in good shape, but need sections covering anonymisation, aggregation, and flow selection techniques) as examples of IPFIX Mediation. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix that, Benoit will work with its author (Randall Stewart) to encourage tsvarea to accept it as a wg item and get it published as soon as possible. The Config Data Model draft was presented by Benoit. It is complete, but depends on having its actual data model written in YANG. YANG is not yet stable, the netconf wg expects to finish it by September 09. We agreed to keep the IPFIX Config Model draft as is, and wait for YANG to become stable. We will review that decision next year. Kobayashi Atsushi presented the two IPFIX Mediation drafts. These have both been updated following list discussion; that discussion continues, but both are nearing completion. Both of them reference three other drafts that had been discussed in the wg (flow anonymisation, aggregation, and flow selection techniques) as examples of IPFIX Mediation. We agreed that the drafts should be revised further to include brief summaries of the 'examples' drafts, and quite a few other issues that have arisen on the mailing list. We believe that those drafts will later reappear as wg work items for Mediation Intermediate Processes using the Mediation Framework. Nevil had circulated a proposed set of milestone changes on the list, they were discussed and amended. Under 'any other business,' it was reported that ippm have considered specifying some metrics derived from passive measurements - IPFIX would be a useful source of such data. Alt Morton commented that Passive Measurements have a low priority in ippm. Brian Trammel reported that he and Elisa Boschi had given an IPFIX tutorial at IMC. The meeting closed at 1020; thanks to Ralf Wolter for his meeting notes. ------------------------------------------------------------ One-para summary: The psamp-info draft is approved, all eight ipfix/psamp drafts can now appear as RFCs. IANA have published the IPFIX Information Elements Registry. Three IPFIX drafts are now complete, Nevil and Juergen will do their writeups and pass them to Dan. The SCTP-per-stream draft is waiting for a tsvarea document, SCTP Stream Reset. Our Config Model is complete, we're waiting to see how soon YANG will be stable. The two IPFIX Mediators drafts are in good shape, but need sections covering anonymisation, aggregation, and flow selection techniques) as examples of IPFIX Mediation. -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 20 19:59:57 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445033A6A74; Thu, 20 Nov 2008 19:59:57 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3469E3A6A71 for ; Thu, 20 Nov 2008 19:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owPUI9FZKbkD for ; Thu, 20 Nov 2008 19:59:55 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id B2F2A3A6A5A for ; Thu, 20 Nov 2008 19:59:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAL3xoN01637; Fri, 21 Nov 2008 04:59:50 +0100 (CET) Received: from [10.86.249.169] (bxb-vpn3-425.cisco.com [10.86.249.169]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAL3xPG01479; Fri, 21 Nov 2008 04:59:25 +0100 (CET) Message-ID: <4926321C.9030403@cisco.com> Date: Thu, 20 Nov 2008 21:59:24 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Christoph Sommer References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> In-Reply-To: <4923D59E.7010209@informatik.uni-erlangen.de> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1671677739==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1671677739== Content-Type: multipart/alternative; boundary="------------030500010205010509030108" This is a multi-part message in MIME format. --------------030500010205010509030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Christoph, All, I agree there is some confusion with regards to the terminology. Here is a proposal IPFIX Mediation IPFIX Mediation is a function that offers one or multiple of the following capabilities: * rerouting input Flow Records/Packet Reports to a appropriate Collecting Process * replicating input Flow Records/Packet Reports * filtering and selecting Flow Records/Packet Report * aggregating input Flow Records/Packet Reports based on a new set of Flow Key field * correlating a set of Flow Records/Packet Reports for creating new Flow Records/Packet Reports with new metrics * changing the transport protocol which carries IPFIX Message * modifying Flow Records/Packet Reports The modification of Flow Records/Packet Reports includes these functions * changing the value of specified Information Elements * adding new Information Elements by deriving further Flow or packet properties from existing fields or calculating new metrics * deleting specified Information Elements. IPFIX Mediation can be included in any IPFIX Devices, such as routers, switches, NMS(Network Management Systems),. In an IPFIX Device, the IPFIX Mediation is located between Exporting Processes and Collecting Processes. IPFIX Mediator The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX Mediations capabilities. IPFIX Proxy An IPFIX Proxy is an IPFIX _Mediation _that receives IPFIX Messages from Original Exporter(s), and sends new IPFIX Messages to one or more Collector(s). For example, it may change the transport protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of IPFIX Proxy is a IPFIX Mediation that converts legacy protocol messages into an IPFIX Message. IPFIX Concentrator An IPFIX Concentrator is an IPFIX Mediation that ... Regards, Benoit. ------------------------------------------------------------------------ > Dear all, > > Atsushi Kobayashi wrote: > >> Gerhard Muenz wrote: >> >>> IPFIX Mediator Problem statement wrote: >>> >>>> IPFIX Mediation is an additional function to suit the needs of some >>>> measurement system. >>>> >>> Isn't IPFIX Mediation supposed to be an umbrella term which includes >>> IPFIX concentrators and IPFIX proxies? >>> >> I mean that IPFIX Mediator is umbrella term which includes IPFIX >> concentrators and IPFIX proxies. But, IPFIX Mediation is not. >> > > I think there is still some confusion on what a number of terms that > came up during IPFIX Mediator discussions mean. Some of them are not > clearly defined and some are used interchangeably. From the top of my > head, these are: > > * IPFIX Mediator > * IPFIX Mediation > * IPFIX Mediation device > * Mediation Function > * Intermediate Function > * Intermediate Process > * Exporter with Mediation Function > * Exporter with Mediation > > How about we settle on a subset and give a clear(er) definition of these > terms? > > > I propose the following two definitions: > > * Intermediate Process: > a black box that processes Flow Records, i.e. that takes > Flow Records as its input and has Flow Records as its output. > > * IPFIX Mediator: > a device that can host zero or more Intermediate Processes > along with other Processes defined in IPFIX. > > > I think these two definitions can be used to describe all > currently-thought-of IPFIX Mediators by using zero or more Intermediate > Processes (IMPs), like so: > > * IPFIX Proxy: > Collector---Exporter > > * IPFIX Concentrator: > Collector---"IMP Aggregator"---Exporter > > * IPFIX Distributor: > Collector---"IMP Distributor"---Exporter(s) > > * IPFIX Masquerading Proxy: > Collector---"IMP Masquerade"---Exporter > > > I would like to hear as many comments/suggestions as possible, so we can > arrive at a clear definition of what an IPFIX Mediator is and what an > Intermediate Process can do! > > > Regards, > > Christoph > > --------------030500010205010509030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christoph, All,

I agree there is some confusion with regards to the terminology.
Here is a proposal

IPFIX Mediation

IPFIX Mediation is a function that offers one or multiple of the following capabilities:
         *  rerouting input Flow Records/Packet Reports to a appropriate Collecting Process
         *  replicating input Flow Records/Packet Reports
         *  filtering and selecting Flow Records/Packet Report
         *  aggregating input Flow Records/Packet Reports based on a new set of Flow Key field
         *  correlating a set of Flow Records/Packet Reports for creating new Flow Records/Packet Reports with new metrics
         *  changing the transport protocol which carries IPFIX Message
         *  modifying Flow Records/Packet Reports
             The modification of Flow Records/Packet Reports includes these functions
                    *  changing the value of specified Information Elements
                    *  adding new Information Elements by deriving further Flow or
                        packet properties from existing fields or calculating new metrics
                    *  deleting specified Information Elements.
IPFIX Mediation can be included in any IPFIX Devices, such as routers,       switches, NMS(Network Management Systems),. In an IPFIX Device, the IPFIX Mediation is located between Exporting Processes and Collecting Processes.

IPFIX Mediator

The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX Mediations capabilities.
 

IPFIX Proxy

 An IPFIX Proxy is an IPFIX Mediation that receives IPFIX Messages from Original Exporter(s), and sends new IPFIX Messages to one or more Collector(s).  For example, it may change the transport protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of IPFIX Proxy is a IPFIX Mediation that converts legacy protocol messages into an IPFIX Message.

IPFIX Concentrator     

An IPFIX Concentrator is an IPFIX Mediation that ...

Regards, Benoit.
Dear all,

Atsushi Kobayashi wrote:
  
Gerhard Muenz wrote:
    
IPFIX Mediator Problem statement wrote:
      
IPFIX Mediation is an additional function to suit the needs of some
measurement system.
        
Isn't IPFIX Mediation supposed to be an umbrella term which includes
IPFIX concentrators and IPFIX proxies?
      
I mean that IPFIX Mediator is umbrella term which includes IPFIX
concentrators and IPFIX proxies. But, IPFIX Mediation is not.
    

I think there is still some confusion on what a number of terms that
came up during IPFIX Mediator discussions mean. Some of them are not
clearly defined and some are used interchangeably. From the top of my
head, these are:

* IPFIX Mediator
* IPFIX Mediation
* IPFIX Mediation device
* Mediation Function
* Intermediate Function
* Intermediate Process
* Exporter with Mediation Function
* Exporter with Mediation

How about we settle on a subset and give a clear(er) definition of these
terms?


I propose the following two definitions:

* Intermediate Process:
  a black box that processes Flow Records, i.e. that takes
  Flow Records as its input and has Flow Records as its output.

* IPFIX Mediator:
  a device that can host zero or more Intermediate Processes
  along with other Processes defined in IPFIX.


I think these two definitions can be used to describe all
currently-thought-of IPFIX Mediators by using zero or more Intermediate
Processes (IMPs), like so:

* IPFIX Proxy:
  Collector---Exporter

* IPFIX Concentrator:
  Collector---"IMP Aggregator"---Exporter

* IPFIX Distributor:
  Collector---"IMP Distributor"---Exporter(s)

* IPFIX Masquerading Proxy:
  Collector---"IMP Masquerade"---Exporter


I would like to hear as many comments/suggestions as possible, so we can
arrive at a clear definition of what an IPFIX Mediator is and what an
Intermediate Process can do!


Regards,

  Christoph

--------------030500010205010509030108-- --===============1671677739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1671677739==-- From ipfix-bounces@ietf.org Thu Nov 20 19:59:57 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445033A6A74; Thu, 20 Nov 2008 19:59:57 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3469E3A6A71 for ; Thu, 20 Nov 2008 19:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.556 X-Spam-Level: X-Spam-Status: No, score=-1.556 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owPUI9FZKbkD for ; Thu, 20 Nov 2008 19:59:55 -0800 (PST) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id B2F2A3A6A5A for ; Thu, 20 Nov 2008 19:59:54 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAL3xoN01637; Fri, 21 Nov 2008 04:59:50 +0100 (CET) Received: from [10.86.249.169] (bxb-vpn3-425.cisco.com [10.86.249.169]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id mAL3xPG01479; Fri, 21 Nov 2008 04:59:25 +0100 (CET) Message-ID: <4926321C.9030403@cisco.com> Date: Thu, 20 Nov 2008 21:59:24 -0600 From: Benoit Claise User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Christoph Sommer References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> In-Reply-To: <4923D59E.7010209@informatik.uni-erlangen.de> Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1671677739==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============1671677739== Content-Type: multipart/alternative; boundary="------------030500010205010509030108" This is a multi-part message in MIME format. --------------030500010205010509030108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Christoph, All, I agree there is some confusion with regards to the terminology. Here is a proposal IPFIX Mediation IPFIX Mediation is a function that offers one or multiple of the following capabilities: * rerouting input Flow Records/Packet Reports to a appropriate Collecting Process * replicating input Flow Records/Packet Reports * filtering and selecting Flow Records/Packet Report * aggregating input Flow Records/Packet Reports based on a new set of Flow Key field * correlating a set of Flow Records/Packet Reports for creating new Flow Records/Packet Reports with new metrics * changing the transport protocol which carries IPFIX Message * modifying Flow Records/Packet Reports The modification of Flow Records/Packet Reports includes these functions * changing the value of specified Information Elements * adding new Information Elements by deriving further Flow or packet properties from existing fields or calculating new metrics * deleting specified Information Elements. IPFIX Mediation can be included in any IPFIX Devices, such as routers, switches, NMS(Network Management Systems),. In an IPFIX Device, the IPFIX Mediation is located between Exporting Processes and Collecting Processes. IPFIX Mediator The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX Mediations capabilities. IPFIX Proxy An IPFIX Proxy is an IPFIX _Mediation _that receives IPFIX Messages from Original Exporter(s), and sends new IPFIX Messages to one or more Collector(s). For example, it may change the transport protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of IPFIX Proxy is a IPFIX Mediation that converts legacy protocol messages into an IPFIX Message. IPFIX Concentrator An IPFIX Concentrator is an IPFIX Mediation that ... Regards, Benoit. ------------------------------------------------------------------------ > Dear all, > > Atsushi Kobayashi wrote: > >> Gerhard Muenz wrote: >> >>> IPFIX Mediator Problem statement wrote: >>> >>>> IPFIX Mediation is an additional function to suit the needs of some >>>> measurement system. >>>> >>> Isn't IPFIX Mediation supposed to be an umbrella term which includes >>> IPFIX concentrators and IPFIX proxies? >>> >> I mean that IPFIX Mediator is umbrella term which includes IPFIX >> concentrators and IPFIX proxies. But, IPFIX Mediation is not. >> > > I think there is still some confusion on what a number of terms that > came up during IPFIX Mediator discussions mean. Some of them are not > clearly defined and some are used interchangeably. From the top of my > head, these are: > > * IPFIX Mediator > * IPFIX Mediation > * IPFIX Mediation device > * Mediation Function > * Intermediate Function > * Intermediate Process > * Exporter with Mediation Function > * Exporter with Mediation > > How about we settle on a subset and give a clear(er) definition of these > terms? > > > I propose the following two definitions: > > * Intermediate Process: > a black box that processes Flow Records, i.e. that takes > Flow Records as its input and has Flow Records as its output. > > * IPFIX Mediator: > a device that can host zero or more Intermediate Processes > along with other Processes defined in IPFIX. > > > I think these two definitions can be used to describe all > currently-thought-of IPFIX Mediators by using zero or more Intermediate > Processes (IMPs), like so: > > * IPFIX Proxy: > Collector---Exporter > > * IPFIX Concentrator: > Collector---"IMP Aggregator"---Exporter > > * IPFIX Distributor: > Collector---"IMP Distributor"---Exporter(s) > > * IPFIX Masquerading Proxy: > Collector---"IMP Masquerade"---Exporter > > > I would like to hear as many comments/suggestions as possible, so we can > arrive at a clear definition of what an IPFIX Mediator is and what an > Intermediate Process can do! > > > Regards, > > Christoph > > --------------030500010205010509030108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christoph, All,

I agree there is some confusion with regards to the terminology.
Here is a proposal

IPFIX Mediation

IPFIX Mediation is a function that offers one or multiple of the following capabilities:
         *  rerouting input Flow Records/Packet Reports to a appropriate Collecting Process
         *  replicating input Flow Records/Packet Reports
         *  filtering and selecting Flow Records/Packet Report
         *  aggregating input Flow Records/Packet Reports based on a new set of Flow Key field
         *  correlating a set of Flow Records/Packet Reports for creating new Flow Records/Packet Reports with new metrics
         *  changing the transport protocol which carries IPFIX Message
         *  modifying Flow Records/Packet Reports
             The modification of Flow Records/Packet Reports includes these functions
                    *  changing the value of specified Information Elements
                    *  adding new Information Elements by deriving further Flow or
                        packet properties from existing fields or calculating new metrics
                    *  deleting specified Information Elements.
IPFIX Mediation can be included in any IPFIX Devices, such as routers,       switches, NMS(Network Management Systems),. In an IPFIX Device, the IPFIX Mediation is located between Exporting Processes and Collecting Processes.

IPFIX Mediator

The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX Mediations capabilities.
 

IPFIX Proxy

 An IPFIX Proxy is an IPFIX Mediation that receives IPFIX Messages from Original Exporter(s), and sends new IPFIX Messages to one or more Collector(s).  For example, it may change the transport protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of IPFIX Proxy is a IPFIX Mediation that converts legacy protocol messages into an IPFIX Message.

IPFIX Concentrator     

An IPFIX Concentrator is an IPFIX Mediation that ...

Regards, Benoit.
Dear all,

Atsushi Kobayashi wrote:
  
Gerhard Muenz wrote:
    
IPFIX Mediator Problem statement wrote:
      
IPFIX Mediation is an additional function to suit the needs of some
measurement system.
        
Isn't IPFIX Mediation supposed to be an umbrella term which includes
IPFIX concentrators and IPFIX proxies?
      
I mean that IPFIX Mediator is umbrella term which includes IPFIX
concentrators and IPFIX proxies. But, IPFIX Mediation is not.
    

I think there is still some confusion on what a number of terms that
came up during IPFIX Mediator discussions mean. Some of them are not
clearly defined and some are used interchangeably. From the top of my
head, these are:

* IPFIX Mediator
* IPFIX Mediation
* IPFIX Mediation device
* Mediation Function
* Intermediate Function
* Intermediate Process
* Exporter with Mediation Function
* Exporter with Mediation

How about we settle on a subset and give a clear(er) definition of these
terms?


I propose the following two definitions:

* Intermediate Process:
  a black box that processes Flow Records, i.e. that takes
  Flow Records as its input and has Flow Records as its output.

* IPFIX Mediator:
  a device that can host zero or more Intermediate Processes
  along with other Processes defined in IPFIX.


I think these two definitions can be used to describe all
currently-thought-of IPFIX Mediators by using zero or more Intermediate
Processes (IMPs), like so:

* IPFIX Proxy:
  Collector---Exporter

* IPFIX Concentrator:
  Collector---"IMP Aggregator"---Exporter

* IPFIX Distributor:
  Collector---"IMP Distributor"---Exporter(s)

* IPFIX Masquerading Proxy:
  Collector---"IMP Masquerade"---Exporter


I would like to hear as many comments/suggestions as possible, so we can
arrive at a clear definition of what an IPFIX Mediator is and what an
Intermediate Process can do!


Regards,

  Christoph

--------------030500010205010509030108-- --===============1671677739== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1671677739==-- From ipfix-bounces@ietf.org Fri Nov 21 03:29:09 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D72C3A68D3; Fri, 21 Nov 2008 03:29:09 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033133A68D3 for ; Fri, 21 Nov 2008 03:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScv4sOgr-iY for ; Fri, 21 Nov 2008 03:29:06 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 8E9093A67A8 for ; Fri, 21 Nov 2008 03:29:06 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E4A8D474AA; Fri, 21 Nov 2008 12:29:03 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 656E646C8; Fri, 21 Nov 2008 12:29:03 +0100 (CET) Message-ID: <49269B8B.7000500@net.in.tum.de> Date: Fri, 21 Nov 2008 12:29:15 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Benoit Claise References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> <4926321C.9030403@cisco.com> In-Reply-To: <4926321C.9030403@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0367885303==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0367885303== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070004090905040509090700" This is a cryptographically signed message in MIME format. --------------ms070004090905040509090700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Benoit Claise wrote: > Christoph, All, >=20 > I agree there is some confusion with regards to the terminology. > Here is a proposal >=20 > IPFIX Mediation >=20 > IPFIX Mediation is a function that offers one or multiple of the > following capabilities: > * rerouting input Flow Records/Packet Reports to a appropriat= e > Collecting Process > * replicating input Flow Records/Packet Reports > * filtering and selecting Flow Records/Packet Report > * aggregating input Flow Records/Packet Reports based on a ne= w > set of Flow Key field > * correlating a set of Flow Records/Packet Reports for > creating new Flow Records/Packet Reports with new metrics > * changing the transport protocol which carries IPFIX Message= From ipfix-bounces@ietf.org Fri Nov 21 03:29:09 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D72C3A68D3; Fri, 21 Nov 2008 03:29:09 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033133A68D3 for ; Fri, 21 Nov 2008 03:29:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScv4sOgr-iY for ; Fri, 21 Nov 2008 03:29:06 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 8E9093A67A8 for ; Fri, 21 Nov 2008 03:29:06 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id E4A8D474AA; Fri, 21 Nov 2008 12:29:03 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 656E646C8; Fri, 21 Nov 2008 12:29:03 +0100 (CET) Message-ID: <49269B8B.7000500@net.in.tum.de> Date: Fri, 21 Nov 2008 12:29:15 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Benoit Claise References: <492150CD.4040101@net.in.tum.de> <20081119003311.E5B7.17391CF2@nttv6.net> <4923D59E.7010209@informatik.uni-erlangen.de> <4926321C.9030403@cisco.com> In-Reply-To: <4926321C.9030403@cisco.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX Mediator - Term Definition X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0367885303==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0367885303== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070004090905040509090700" This is a cryptographically signed message in MIME format. --------------ms070004090905040509090700 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Benoit Claise wrote: > Christoph, All, >=20 > I agree there is some confusion with regards to the terminology. > Here is a proposal >=20 > IPFIX Mediation >=20 > IPFIX Mediation is a function that offers one or multiple of the > following capabilities: > * rerouting input Flow Records/Packet Reports to a appropriat= e > Collecting Process > * replicating input Flow Records/Packet Reports > * filtering and selecting Flow Records/Packet Report > * aggregating input Flow Records/Packet Reports based on a ne= w > set of Flow Key field > * correlating a set of Flow Records/Packet Reports for > creating new Flow Records/Packet Reports with new metrics > * changing the transport protocol which carries IPFIX Message > * modifying Flow Records/Packet Reports > The modification of Flow Records/Packet Reports includes > these functions > * changing the value of specified Information Elem= ents > * adding new Information Elements by deriving > further Flow or > packet properties from existing fields or > calculating new metrics > * deleting specified Information Elements. > IPFIX Mediation can be included in any IPFIX Devices, such as routers, > switches, NMS(Network Management Systems),. In an IPFIX Device, > the IPFIX Mediation is located between Exporting Processes and > Collecting Processes. "IPFIX Mediation is a function that offers one or multiple capabilities" sounds a bit strange to me. Instead, we could define: IPFIX Mediation Function =3D Any functions that can be applied to entire messages or individual records of IPFIX and related protocols. Examples are: ... Intermediate Process (or: Mediation Process) =3D Process that implements one or more IPFIX Mediation Functions. > IPFIX Mediator >=20 > The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX > Mediations capabilities. As far as I understood, IPFIX Mediator was previously defined as a device that contains at least one Collecting Process and one Exporting Process: CP --> some mediation function --> EP So, if a Mediation Function is applied at an Exporter that does not have any Collecting Process, it is _not_ an IPFIX Mediator: CP --> MP --> some mediation function --> EP Of course, we can remove the restriction and say any device capable of doing any mediation is an IPFIX Mediator. Yet, I would prefer to say: An IPFIX Mediator is an IPFIX Device that contains one or more Mediation/Intermediate Processes. > IPFIX Proxy >=20 > An IPFIX Proxy is an IPFIX Mediation that receives IPFIX Messages= > from Original Exporter(s), and sends new IPFIX Messages to one or > more Collector(s). For example, it may change the transport > protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of > IPFIX Proxy is a IPFIX Mediation that converts legacy protocol > messages into an IPFIX Message. This definition does not work because "that receives IPFIX Messages from Original Exporter(s)" prevents the reception of legacy protocols. See also my proposed definition in another mail. Regards, Gerhard >=20 > IPFIX Concentrator =20 >=20 > An IPFIX Concentrator is an IPFIX Mediation that ... >=20 > Regards, Benoit. >=20 >> Dear all, >> >> Atsushi Kobayashi wrote: >> =20 >>> Gerhard Muenz wrote: >>> =20 >>>> IPFIX Mediator Problem statement wrote: >>>> =20 >>>>> IPFIX Mediation is an additional function to suit the needs of some= >>>>> measurement system. >>>>> =20 >>>> Isn't IPFIX Mediation supposed to be an umbrella term which includes= >>>> IPFIX concentrators and IPFIX proxies? >>>> =20 >>> I mean that IPFIX Mediator is umbrella term which includes IPFIX >>> concentrators and IPFIX proxies. But, IPFIX Mediation is not. >>> =20 >> I think there is still some confusion on what a number of terms that >> came up during IPFIX Mediator discussions mean. Some of them are not >> clearly defined and some are used interchangeably. From the top of my >> head, these are: >> >> * IPFIX Mediator >> * IPFIX Mediation >> * IPFIX Mediation device >> * Mediation Function >> * Intermediate Function >> * Intermediate Process >> * Exporter with Mediation Function >> * Exporter with Mediation >> >> How about we settle on a subset and give a clear(er) definition of the= se >> terms? >> >> >> I propose the following two definitions: >> >> * Intermediate Process: >> a black box that processes Flow Records, i.e. that takes >> Flow Records as its input and has Flow Records as its output. >> >> * IPFIX Mediator: >> a device that can host zero or more Intermediate Processes >> along with other Processes defined in IPFIX. >> >> >> I think these two definitions can be used to describe all >> currently-though= > * modifying Flow Records/Packet Reports > The modification of Flow Records/Packet Reports includes > these functions > * changing the value of specified Information Elem= ents > * adding new Information Elements by deriving > further Flow or > packet properties from existing fields or > calculating new metrics > * deleting specified Information Elements. > IPFIX Mediation can be included in any IPFIX Devices, such as routers, > switches, NMS(Network Management Systems),. In an IPFIX Device, > the IPFIX Mediation is located between Exporting Processes and > Collecting Processes. "IPFIX Mediation is a function that offers one or multiple capabilities" sounds a bit strange to me. Instead, we could define: IPFIX Mediation Function =3D Any functions that can be applied to entire messages or individual records of IPFIX and related protocols. Examples are: ... Intermediate Process (or: Mediation Process) =3D Process that implements one or more IPFIX Mediation Functions. > IPFIX Mediator >=20 > The IPFIX Mediator is an IPFIX Device that contains one or more IPFIX > Mediations capabilities. As far as I understood, IPFIX Mediator was previously defined as a device that contains at least one Collecting Process and one Exporting Process: CP --> some mediation function --> EP So, if a Mediation Function is applied at an Exporter that does not have any Collecting Process, it is _not_ an IPFIX Mediator: CP --> MP --> some mediation function --> EP Of course, we can remove the restriction and say any device capable of doing any mediation is an IPFIX Mediator. Yet, I would prefer to say: An IPFIX Mediator is an IPFIX Device that contains one or more Mediation/Intermediate Processes. > IPFIX Proxy >=20 > An IPFIX Proxy is an IPFIX Mediation that receives IPFIX Messages= > from Original Exporter(s), and sends new IPFIX Messages to one or > more Collector(s). For example, it may change the transport > protocol, such as UDP, TCP, SCTP and PR-SCTP. A specific type of > IPFIX Proxy is a IPFIX Mediation that converts legacy protocol > messages into an IPFIX Message. This definition does not work because "that receives IPFIX Messages from Original Exporter(s)" prevents the reception of legacy protocols. See also my proposed definition in another mail. Regards, Gerhard >=20 > IPFIX Concentrator =20 >=20 > An IPFIX Concentrator is an IPFIX Mediation that ... >=20 > Regards, Benoit. >=20 >> Dear all, >> >> Atsushi Kobayashi wrote: >> =20 >>> Gerhard Muenz wrote: >>> =20 >>>> IPFIX Mediator Problem statement wrote: >>>> =20 >>>>> IPFIX Mediation is an additional function to suit the needs of some= >>>>> measurement system. >>>>> =20 >>>> Isn't IPFIX Mediation supposed to be an umbrella term which includes= >>>> IPFIX concentrators and IPFIX proxies? >>>> =20 >>> I mean that IPFIX Mediator is umbrella term which includes IPFIX >>> concentrators and IPFIX proxies. But, IPFIX Mediation is not. >>> =20 >> I think there is still some confusion on what a number of terms that >> came up during IPFIX Mediator discussions mean. Some of them are not >> clearly defined and some are used interchangeably. From the top of my >> head, these are: >> >> * IPFIX Mediator >> * IPFIX Mediation >> * IPFIX Mediation device >> * Mediation Function >> * Intermediate Function >> * Intermediate Process >> * Exporter with Mediation Function >> * Exporter with Mediation >> >> How about we settle on a subset and give a clear(er) definition of the= se >> terms? >> >> >> I propose the following two definitions: >> >> * Intermediate Process: >> a black box that processes Flow Records, i.e. that takes >> Flow Records as its input and has Flow Records as its output. >> >> * IPFIX Mediator: >> a device that can host zero or more Intermediate Processes >> along with other Processes defined in IPFIX. >> >> >> I think these two definitions can be used to describe all >> currently-thout-of IPFIX Mediators by using zero or more Intermediat= e >> Processes (IMPs), like so: >> >> * IPFIX Proxy: >> Collector---Exporter >> >> * IPFIX Concentrator: >> Collector---"IMP Aggregator"---Exporter >> >> * IPFIX Distributor: >> Collector---"IMP Distributor"---Exporter(s) >> >> * IPFIX Masquerading Proxy: >> Collector---"IMP Masquerade"---Exporter >> >> >> I would like to hear as many comments/suggestions as possible, so we c= an >> arrive at a clear definition of what an IPFIX Mediator is and what an >> Intermediate Process can do! >> >> >> Regards, >> >> Christoph >> >> =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070004090905040509090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFght-of IPFIX Mediators by using zero or more Intermediat= e >> Processes (IMPs), like so: >> >> * IPFIX Proxy: >> Collector---Exporter >> >> * IPFIX Concentrator: >> Collector---"IMP Aggregator"---Exporter >> >> * IPFIX Distributor: >> Collector---"IMP Distributor"---Exporter(s) >> >> * IPFIX Masquerading Proxy: >> Collector---"IMP Masquerade"---Exporter >> >> >> I would like to hear as many comments/suggestions as possible, so we c= an >> arrive at a clear definition of what an IPFIX Mediator is and what an >> Intermediate Process can do! >> >> >> Regards, >> >> Christoph >> >> =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms070004090905040509090700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyMTExMjkxNVowIwYJKoZIhvcNAQkEMRYEFCo8HU05kZeT i+QoLASxnEEZl6giMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQDFskfjuSkQFFrKJOXKRbMst1tpcMXFafVPf6k5fwzArmqlrbdQrxekjXHM m7fVAGh/eo2HVWWS9uRZofHjl9rAJyTSU1+rklk/h5X4t048QEFxKFh2V4xJ1oVoy6va8bgw I2FEXyhr5GVgbr5vE7J76mgEsYV7HF7DgN4KT46BNPWTODDN8iT+qgP+cFtthtUutRl26j/z 1IaO5snFJk7MSWHqXbQRhZQaKGWeW4fvIJitjoheeNp10xaenSN9S0UShNeDoamxKblYWaGG 6p1dRJl56qSsZ4bt/eOO8FnqZ0bLflN5YgR5dqwMgO5xK4kRCtAWtLgceqEoZHWqcs32AAAA AAAA --------------ms070004090905040509090700-- --===============0367885303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0367885303==-- WFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyMTExMjkxNVowIwYJKoZIhvcNAQkEMRYEFCo8HU05kZeT i+QoLASxnEEZl6giMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQDFskfjuSkQFFrKJOXKRbMst1tpcMXFafVPf6k5fwzArmqlrbdQrxekjXHM m7fVAGh/eo2HVWWS9uRZofHjl9rAJyTSU1+rklk/h5X4t048QEFxKFh2V4xJ1oVoy6va8bgw I2FEXyhr5GVgbr5vE7J76mgEsYV7HF7DgN4KT46BNPWTODDN8iT+qgP+cFtthtUutRl26j/z 1IaO5snFJk7MSWHqXbQRhZQaKGWeW4fvIJitjoheeNp10xaenSN9S0UShNeDoamxKblYWaGG 6p1dRJl56qSsZ4bt/eOO8FnqZ0bLflN5YgR5dqwMgO5xK4kRCtAWtLgceqEoZHWqcs32AAAA AAAA --------------ms070004090905040509090700-- --===============0367885303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0367885303==-- From ipfix-bounces@ietf.org Fri Nov 21 07:39:33 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29163A6925; Fri, 21 Nov 2008 07:39:33 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611953A6964 for ; Fri, 21 Nov 2008 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY0vhrwqQUgS for ; Fri, 21 Nov 2008 07:39:30 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D60C33A67E2 for ; Fri, 21 Nov 2008 07:39:29 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mALFdMfU031796; Sat, 22 Nov 2008 00:39:26 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 22 Nov 2008 00:39:26 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4925DD8A.6070306@net.in.tum.de> References: <20081121050251.0A57.17391CF2@nttv6.net> <4925DD8A.6070306@net.in.tum.de> Message-Id: <20081121232637.9489.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Sat, 22 Nov 2008 00:39:27 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Please see inline. On Thu, 20 Nov 2008 22:58:34 +0100 Gerhard Muenz wrote: > > Hello Atsushi, > > Some answers inline. > > Regards, > Gerhard > > Atsushi Kobayashi wrote: > >>> Mediator Observation Domain > >>> > >>> An IPFIX Mediator does not host the Observation Points and > >> Why should we disallow IPFIX Mediators which also have native > >> Observation Points? > >> > >>> Observation Domain. The Observation Domain ID in the IPFIX header > >>> sent by the IPFIX Mediator also indicates the largest set of > >>> Observation Points from the viewpoint of a Collector. However, > >> This seems to be too generic. The ODID issued by the mediator should > >> identify the set of ODs/OPs the exported records belong to. > > > > Yes. > > > >> It does not always have to be the "largest set of OPs", it can be a subset. > >> > > Certainly, yes. > > > >> As an example, the Mediator may be configured not to merge records from > >> different OPs at all. In this case, we can keep the old OIDs. Or it may > >> be configured to merge records from a specific subset of OPs only. > >> > > Based on your comments, I think that term "Mediator Observation Domain" > > is unnecessary. Because term "Observation Domain" can be applied to > > IPFIX Mediator as well, and the meaning is not changed. > > > > Is it better to remove this term? > > Not sure. > > RFC 5101 says: > > Observation Domain > > An ObservatFrom ipfix-bounces@ietf.org Fri Nov 21 07:39:33 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C29163A6925; Fri, 21 Nov 2008 07:39:33 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611953A6964 for ; Fri, 21 Nov 2008 07:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY0vhrwqQUgS for ; Fri, 21 Nov 2008 07:39:30 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D60C33A67E2 for ; Fri, 21 Nov 2008 07:39:29 -0800 (PST) Received: from [127.0.0.1] (mail.nttv6.net [192.16.178.5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mALFdMfU031796; Sat, 22 Nov 2008 00:39:26 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sat, 22 Nov 2008 00:39:26 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4925DD8A.6070306@net.in.tum.de> References: <20081121050251.0A57.17391CF2@nttv6.net> <4925DD8A.6070306@net.in.tum.de> Message-Id: <20081121232637.9489.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [192.16.178.5]); Sat, 22 Nov 2008 00:39:27 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhard, Please see inline. On Thu, 20 Nov 2008 22:58:34 +0100 Gerhard Muenz wrote: > > Hello Atsushi, > > Some answers inline. > > Regards, > Gerhard > > Atsushi Kobayashi wrote: > >>> Mediator Observation Domain > >>> > >>> An IPFIX Mediator does not host the Observation Points and > >> Why should we disallow IPFIX Mediators which also have native > >> Observation Points? > >> > >>> Observation Domain. The Observation Domain ID in the IPFIX header > >>> sent by the IPFIX Mediator also indicates the largest set of > >>> Observation Points from the viewpoint of a Collector. However, > >> This seems to be too generic. The ODID issued by the mediator should > >> identify the set of ODs/OPs the exported records belong to. > > > > Yes. > > > >> It does not always have to be the "largest set of OPs", it can be a subset. > >> > > Certainly, yes. > > > >> As an example, the Mediator may be configured not to merge records from > >> different OPs at all. In this case, we can keep the old OIDs. Or it may > >> be configured to merge records from a specific subset of OPs only. > >> > > Based on your comments, I think that term "Mediator Observation Domain" > > is unnecessary. Because term "Observation Domain" can be applied to > > IPFIX Mediator as well, and the meaning is not changed. > > > > Is it better to remove this term? > > Not sure. > > RFC 5101 says: > > Observation Domain > > An Observatioion Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > ... In second thought, I think that ODID issued by Mediator becomes the largest set of Observation Points from viewpoint of Collector, even if Mediator merges records from a specific subset of OPs only. Simply, I would like to say the following just like RFC5101 mention. A Mediator Observation Domain indicates the largest set of Observation Points for which Flow information can be aggregated by a Mediator. Is it correct? During second thought, I start to confuse your questions. > > Observation Domain ID > > ... The Observation > Domain ID SHOULD be 0 when no specific Observation Domain ID is > relevant for the entire IPFIX Message, for example, when exporting > the Exporting Process Statistics, or in case of a hierarchy of > Collectors when aggregated Data Records are exported. > > The last sentence already covers the problem of aggregation. > > If you are happy with ODID=0 for Mediators, then you do not have to > introduce "Mediator Observation Domain". If you want to use other > values, maybe it is necessary to introduce a new term here. Good point. I would like to introduce this term. > > > > >>> this value does not indicate the physical entity of an Original > >>> Exporter. > > > >>> 3. IPFIX Mediation Reference Model > >>> > >>> > >>> The figure below shows the high-level reference model for IPFIX > >>> Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > >>> the various possible scenarios that can exist in an IPFIX measurement > >>> system. > >>> > >>> > >>> +---------------------------+ +---------------------------+ > >>> | Collector {l} | | Collector {k} | > >>> |[*Application(s)] | |[*Application(s)] | > >>> |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > >>> |[Collecting Process(es)] |....|[Collecting Process(es)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ ^ > >>> | | | | > >>> | +------....----+ | > >>> | | | > >>> IPFIX (Flow Records / Packet Reports) > >>> | | | > >>> +----------------+----+-----+ +-------+-------------------+ > >>> |IPFIX Mediator {j} | |IPFIX Mediator {n} | > >>> |[*Applications(s)] | |[*Applications(s)] | > >>> |[Exporting Process(es)] | |[Exporting Process(es)] | > >>> |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > >>> |[Collecting Process(es)] | |[Collecting Process(es)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ > >>> | | | > >>> | +------....-----+ > >>> | | > >>> IPFIX (Flow Records / Packet Reports) > >>> | | > >>> +----------------+----------+ +----+----------------------+ > >>> |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > >>> |[Exporting Process(es)] | |[Exporting Process(es)] | > >>> |[Metering Process(es)] |....|[Metering Process(es)] | > >>> |[Observation Point(s)] | |[Observation Point(s)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ ^ > >>> | | | | > >>> Packets coming in to Observation Points > >>> > >>> Figure A: Reference Model for IPFIX Mediation. > >>> > >>> The various functional components are indicated within brackets []. > >>> The functional components within [*] are not part of > >>> [I-D.ietn Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > ... In second thought, I think that ODID issued by Mediator becomes the largest set of Observation Points from viewpoint of Collector, even if Mediator merges records from a specific subset of OPs only. Simply, I would like to say the following just like RFC5101 mention. A Mediator Observation Domain indicates the largest set of Observation Points for which Flow information can be aggregated by a Mediator. Is it correct? During second thought, I start to confuse your questions. > > Observation Domain ID > > ... The Observation > Domain ID SHOULD be 0 when no specific Observation Domain ID is > relevant for the entire IPFIX Message, for example, when exporting > the Exporting Process Statistics, or in case of a hierarchy of > Collectors when aggregated Data Records are exported. > > The last sentence already covers the problem of aggregation. > > If you are happy with ODID=0 for Mediators, then you do not have to > introduce "Mediator Observation Domain". If you want to use other > values, maybe it is necessary to introduce a new term here. Good point. I would like to introduce this term. > > > > >>> this value does not indicate the physical entity of an Original > >>> Exporter. > > > >>> 3. IPFIX Mediation Reference Model > >>> > >>> > >>> The figure below shows the high-level reference model for IPFIX > >>> Mediation based on [I-D.ietf-ipfix-architecture]. This figure covers > >>> the various possible scenarios that can exist in an IPFIX measurement > >>> system. > >>> > >>> > >>> +---------------------------+ +---------------------------+ > >>> | Collector {l} | | Collector {k} | > >>> |[*Application(s)] | |[*Application(s)] | > >>> |[IPFIX File Reader/Writer] | |[IPFIX File Reader/Writer] | > >>> |[Collecting Process(es)] |....|[Collecting Process(es)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ ^ > >>> | | | | > >>> | +------....----+ | > >>> | | | > >>> IPFIX (Flow Records / Packet Reports) > >>> | | | > >>> +----------------+----+-----+ +-------+-------------------+ > >>> |IPFIX Mediator {j} | |IPFIX Mediator {n} | > >>> |[*Applications(s)] | |[*Applications(s)] | > >>> |[Exporting Process(es)] | |[Exporting Process(es)] | > >>> |[Intermediate Process(es)] |....|[Intermediate Process(es)] | > >>> |[Collecting Process(es)] | |[Collecting Process(es)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ > >>> | | | > >>> | +------....-----+ > >>> | | > >>> IPFIX (Flow Records / Packet Reports) > >>> | | > >>> +----------------+----------+ +----+----------------------+ > >>> |IPFIX Original Exporter {i}| |IPFIX Original Exporter {m}| > >>> |[Exporting Process(es)] | |[Exporting Process(es)] | > >>> |[Metering Process(es)] |....|[Metering Process(es)] | > >>> |[Observation Point(s)] | |[Observation Point(s)] | > >>> +---------------------------+ +---------------------------+ > >>> ^ ^ ^ ^ > >>> | | | | > >>> Packets coming in to Observation Points > >>> > >>> Figure A: Reference Model for IPFIX Mediation. > >>> > >>> The various functional components are indicated within brackets []. > >>> The functional components within [*] are not part of > >>> [I-D.ietf-f-ipfix-architecture]. > >> Hm. Intermediate Process as well as IPFIX reader/writer are not part of > >> ipfix-architecture either. > >> > > > > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it > > make sense? > > Ok. You could also remove the Applications from the figure. > Ok. > >>> 4.3. Intermediate Process > >>> > >>> > >>> Intermediate Processes generate new sets of Flow Records/Packet > >>> Reports from input Flow Records/Packet Reports with IPFIX header > >>> information "Export Time" and "Observation Domain ID". The processes > >> I would not call it "IPFIX header information" because there are no > >> IPFIX Messages at the input of the Intermediate Process, only Records. > >> Maybe "context information collected at the Collecting Process"? > >> > > > > I will improve as follows. > > > > Intermediate Processes generate new sets of Flow Records/Packet > > Reports from input Flow Records/Packet Reports with context information > > collected at the Collecting Process that includes "Export Time" and > > "Observation Domain ID". > > > > Is it OK? > > Yes, that sounds good. Thank you. > > > >>> 4.3.2. Flow-based Collector Selection Function > >>> > >>> > >>> The Flow-based Collector Selection function determines to which > >>> Collector input Flow Records/Packet Reports are exported. The > >>> function may also determine the type of Transport Session. The > >> This functional description conflicts with the Exporting Process. In my > >> opinion, the Exporting Process holds the information about the > >> Collectors, transport protocol etc. > >> > >>> function evaluates the value of a specified Information Element in > >>> input Flow Records/Packet Reports and then selects the Collector. > >> So, what is the difference between Flow-Based Colelctor Selection > >> Function and Flow Selection Function plus Exporting Process? > >> > >> I'm not sure if Flow-based Collector Selection should be a function of > >> its own. I would rather say that it describes a use-case of one or > >> multiple Flow Selection Functions and Exporting Processes: > >> > >> +--> Flow Selector 1 -> EP 1 > >> ----+ > >> +--> Flow Selector 2 -> EP 2 > >> > >> > > > > Actually, I have been wondering in which Flow-based Collector Selection > > function should be located in, Metering Process or Exporting Process. > > You mean: in the Intermediate Process or Exporting Process? > Yes. I means in the Intermediate Process or Exporting Process. > > And also, Flow-based Collector Selection function is special case of > > Selection function. Term "Flow-based Collector Selection" seems to be > > unnecessary. > > > > Your opinion is reasonable. I will try to write down your idea. > > > > >>> Space Composition > >>> > >>> Space composition is defined as aggregation on a larger > >>> Observation Domain or on a set of Observation Points. In that > >>> case, a Flow key can be applied to other properties, such as > >> What do you mean by "a Flow Key can be applied to "? > >> > > > > Maybe, it is English issue. > > > > Generally, Flow Key fields are included in Flow Records. But, in that > > case, other properties that are not included in Flow Records, such as > > Exporter IP address or Observation Domain ID, become Flow Key fields. > > > > Is it OK? > > Yes, that's better. > Thank you. > > >>> 4.4. IPFIX File Writer/Reader > >>> > >>> > >>> The IPFIX File Writer stores input Flow Records/Packet Reports from > >>> any process in a storage system. If received Flow Records/Packet > >> It's a "file system". > >> > >>> Reports include uninteresting Information Elements, the Modification > >>> Function can delete these elements before the IPFIX File Writer > >>> handles them. Therefore, IPFIX File Writers can accept input from > >>> any process. In either case, input needs to include the IPFIX header > >> Remove the whole sentence "Therefore,..." > >> > >>> information and the Transport Session Information along with Flow > >>> Recordipfix-architecture]. > >> Hm. Intermediate Process as well as IPFIX reader/writer are not part of > >> ipfix-architecture either. > >> > > > > Please replace "[I-D.ietf-ipfix-architecture]" with this draft. Does it > > make sense? > > Ok. You could also remove the Applications from the figure. > Ok. > >>> 4.3. Intermediate Process > >>> > >>> > >>> Intermediate Processes generate new sets of Flow Records/Packet > >>> Reports from input Flow Records/Packet Reports with IPFIX header > >>> information "Export Time" and "Observation Domain ID". The processes > >> I would not call it "IPFIX header information" because there are no > >> IPFIX Messages at the input of the Intermediate Process, only Records. > >> Maybe "context information collected at the Collecting Process"? > >> > > > > I will improve as follows. > > > > Intermediate Processes generate new sets of Flow Records/Packet > > Reports from input Flow Records/Packet Reports with context information > > collected at the Collecting Process that includes "Export Time" and > > "Observation Domain ID". > > > > Is it OK? > > Yes, that sounds good. Thank you. > > > >>> 4.3.2. Flow-based Collector Selection Function > >>> > >>> > >>> The Flow-based Collector Selection function determines to which > >>> Collector input Flow Records/Packet Reports are exported. The > >>> function may also determine the type of Transport Session. The > >> This functional description conflicts with the Exporting Process. In my > >> opinion, the Exporting Process holds the information about the > >> Collectors, transport protocol etc. > >> > >>> function evaluates the value of a specified Information Element in > >>> input Flow Records/Packet Reports and then selects the Collector. > >> So, what is the difference between Flow-Based Colelctor Selection > >> Function and Flow Selection Function plus Exporting Process? > >> > >> I'm not sure if Flow-based Collector Selection should be a function of > >> its own. I would rather say that it describes a use-case of one or > >> multiple Flow Selection Functions and Exporting Processes: > >> > >> +--> Flow Selector 1 -> EP 1 > >> ----+ > >> +--> Flow Selector 2 -> EP 2 > >> > >> > > > > Actually, I have been wondering in which Flow-based Collector Selection > > function should be located in, Metering Process or Exporting Process. > > You mean: in the Intermediate Process or Exporting Process? > Yes. I means in the Intermediate Process or Exporting Process. > > And also, Flow-based Collector Selection function is special case of > > Selection function. Term "Flow-based Collector Selection" seems to be > > unnecessary. > > > > Your opinion is reasonable. I will try to write down your idea. > > > > >>> Space Composition > >>> > >>> Space composition is defined as aggregation on a larger > >>> Observation Domain or on a set of Observation Points. In that > >>> case, a Flow key can be applied to other properties, such as > >> What do you mean by "a Flow Key can be applied to "? > >> > > > > Maybe, it is English issue. > > > > Generally, Flow Key fields are included in Flow Records. But, in that > > case, other properties that are not included in Flow Records, such as > > Exporter IP address or Observation Domain ID, become Flow Key fields. > > > > Is it OK? > > Yes, that's better. > Thank you. > > >>> 4.4. IPFIX File Writer/Reader > >>> > >>> > >>> The IPFIX File Writer stores input Flow Records/Packet Reports from > >>> any process in a storage system. If received Flow Records/Packet > >> It's a "file system". > >> > >>> Reports include uninteresting Information Elements, the Modification > >>> Function can delete these elements before the IPFIX File Writer > >>> handles them. Therefore, IPFIX File Writers can accept input from > >>> any process. In either case, input needs to include the IPFIX header > >> Remove the whole sentence "Therefore,..." > >> > >>> information and the Transport Session Information along with Flow > >>> Records/s/Packet Reports. > >> Why does the File Writer require header information and transport > >> session information as input? > >> We should not specify additional restrictions for the File Writer here. > >> Also, there are cases where there are no headers and no transport > >> sessions, e.g. if the writer is linked to a Metering Process. > >> > > > > OK. But, if I'm not mistaken, I think that IPFIX file format includes > > session information and Observation Domain ID. > > One IPFIX file corresponds to one transport session. So, there is no > further information required. The ODID is included in the Message > headers as usual. > I mean that IPFIX File Writer should receive the incoming IPFIX header information and incoming Transport Session information in addition to Data Records in order to comply with IPFIX File format, even if Intermediate Process send them. They do not indicate outgoing IPFIX header information and outgoing Transport Session information. Therefore, I do not intend to add special restriction. Did my description make you confuse? > > I don't intend to add other restrictions for the File Writer. > > > > I will read more IPFIX file format draft. > > >>> 4.6. Information Model > >>> > >>> > >>> IPFIX Mediation reuse the general information model from [RFC5101] > >>> and from [I-D.ietf-psamp-info]. The following new Information > >>> Elements for IPFIX Mediation are also needed. > >>> > >>> +-----+---------------------------+-----+---------------------------+ > >>> | ID | Name | ID | Name | > >>> +-----+---------------------------+-----+---------------------------+ > >>> | XXX | averageBitRate | XXX | averagePacketsRate | > >>> | XXX | minimumBitRate | XXX | minimumPacketsRate | > >>> | XXX | maximumBitRate | XXX | maximumPacketsRate | > >>> +-----+---------------------------+-----+---------------------------+ > >> I'm not sure if we should start exporting "rate" IEs. Rates do not > >> represent stable metrics. It's always better to measure "counts". So, I > >> suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. > >> > > Certainly, yes. > > > > If proposing "maximumPacketDeltaCount", we also need to propose other > > Information Element that shows time period of original Flow Records. > > Yes, of course. > Ok. Thank you for your suggestion. > > Because the start time and end time of Flow Record are changed in > > Mediator. Collector can not recognize the delta time. > > > > What do yo think? > > > >> I do not understand why average rate is needed. You easily get the > >> average rate by dividing the delta count of the entire measurement > >> interval by the interval length. > >> > > Actually, Yes. > > > > But, this subsection is pointed out yesterday at IPFIX meeting. > > The definition of Information Elements should not be described in > > framework draft as Informational. > > > > Therefore, I will write down more conceptional idea only. > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix Packet Reports. > >> Why does the File Writer require header information and transport > >> session information as input? > >> We should not specify additional restrictions for the File Writer here. > >> Also, there are cases where there are no headers and no transport > >> sessions, e.g. if the writer is linked to a Metering Process. > >> > > > > OK. But, if I'm not mistaken, I think that IPFIX file format includes > > session information and Observation Domain ID. > > One IPFIX file corresponds to one transport session. So, there is no > further information required. The ODID is included in the Message > headers as usual. > I mean that IPFIX File Writer should receive the incoming IPFIX header information and incoming Transport Session information in addition to Data Records in order to comply with IPFIX File format, even if Intermediate Process send them. They do not indicate outgoing IPFIX header information and outgoing Transport Session information. Therefore, I do not intend to add special restriction. Did my description make you confuse? > > I don't intend to add other restrictions for the File Writer. > > > > I will read more IPFIX file format draft. > > >>> 4.6. Information Model > >>> > >>> > >>> IPFIX Mediation reuse the general information model from [RFC5101] > >>> and from [I-D.ietf-psamp-info]. The following new Information > >>> Elements for IPFIX Mediation are also needed. > >>> > >>> +-----+---------------------------+-----+---------------------------+ > >>> | ID | Name | ID | Name | > >>> +-----+---------------------------+-----+---------------------------+ > >>> | XXX | averageBitRate | XXX | averagePacketsRate | > >>> | XXX | minimumBitRate | XXX | minimumPacketsRate | > >>> | XXX | maximumBitRate | XXX | maximumPacketsRate | > >>> +-----+---------------------------+-----+---------------------------+ > >> I'm not sure if we should start exporting "rate" IEs. Rates do not > >> represent stable metrics. It's always better to measure "counts". So, I > >> suggest to have maximumPacketDeltaCount instead of maximumPacketsRate etc. > >> > > Certainly, yes. > > > > If proposing "maximumPacketDeltaCount", we also need to propose other > > Information Element that shows time period of original Flow Records. > > Yes, of course. > Ok. Thank you for your suggestion. > > Because the start time and end time of Flow Record are changed in > > Mediator. Collector can not recognize the delta time. > > > > What do yo think? > > > >> I do not understand why average rate is needed. You easily get the > >> average rate by dividing the delta count of the entire measurement > >> interval by the interval length. > >> > > Actually, Yes. > > > > But, this subsection is pointed out yesterday at IPFIX meeting. > > The definition of Information Elements should not be described in > > framework draft as Informational. > > > > Therefore, I will write down more conceptional idea only. > > -- > Dipl.-Ing. Gerhard M$B".(Bz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit$BgU(B M$B".(Bchen > Boltzmannstr. 3, 85748 Garching bei M$B".(Bchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > -- Atsushi Kobayashi _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 21 08:54:01 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB69128C0EF; Fri, 21 Nov 2008 08:54:01 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439D428C0F8 for ; Fri, 21 Nov 2008 08:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrK1ZFfoZKat for ; Fri, 21 Nov 2008 08:54:00 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 1DBDB28C0EF for ; Fri, 21 Nov 2008 08:53:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E695F9D76F; Sat, 22 Nov 2008 05:53:54 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfjLsEd9JP1h; Sat, 22 Nov 2008 05:53:54 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 797E69D76D; Sat, 22 Nov 2008 05:53:35 +1300 (NZDT) Message-ID: <4926E78B.2060200@auckland.ac.nz> Date: Sat, 22 Nov 2008 05:53:31 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: boschie@tik.ee.ethz.ch, trammell@tik.ee.ethz.ch, dressler@informatik.uni-erlangen.de, christoph.sommer@informatik.uni-erlangen.de, muenz@net.in.tum.de, akoba@nttv6.net, lorenzo.peluso@fokus.fraunhofer.de, zseby@fokus.fraunhofer.de, maurizio.molina@dante.org.uk Cc: IPFIX list Subject: [IPFIX] Request for summaries of "Mediator-Framework-based" drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi draft authors: The IPFIX Mediation drafts we're currently considering have informative references to your individual drafts listed below. For example, they are used in the Mediation Problem Statement draft to give clear examples of what Mediators can do. At this week's IPFIX session in Minneapolis, we agreed that it would be better not to have references to "work in Progress" drafts. Instead, we'd like to include brief summaries, say two or three paragraphs, maybe a page each. In order to help the Mediation draft editors, and to make sure that those summaries accurately portray the intent of your drafts, could you please write a brief summary for each of your drafts, end email it to the IPFIX list? Once we have consensus on the Mediaton drafts, the next step for the Working Group will be to consider new WG items. Standards Track drafts on mediators, conforming to the Mediation Framework, will be obvious candidates for new IPFIX work. The drafts we need summaries for are: [I-D.boschi-ipfix-anon] Boschi, E. and B. Trammell, "IP Flow Anonymisation Support", draft-boschi-ipfix-anon-01.txt (work in progress) , July 2008. [I-D.dressler-ipfix-aggregation] Dressler, F., Sommer, C., Muenz, G., and A. Kobayashi, "IPFIX Aggregation", draft-dressler-ipfix-aggregation-05.txt (work in progress) , July 2008. [I-D.peluso-flowselection] Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow selection Techniques", draft-peluso-flowselection-tech-01.txt (work in progress) , November 2007. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 21 08:54:01 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB69128C0EF; Fri, 21 Nov 2008 08:54:01 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439D428C0F8 for ; Fri, 21 Nov 2008 08:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrK1ZFfoZKat for ; Fri, 21 Nov 2008 08:54:00 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by core3.amsl.com (Postfix) with ESMTP id 1DBDB28C0EF for ; Fri, 21 Nov 2008 08:53:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E695F9D76F; Sat, 22 Nov 2008 05:53:54 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfjLsEd9JP1h; Sat, 22 Nov 2008 05:53:54 +1300 (NZDT) Received: from [130.129.31.173] (unknown [130.129.31.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 797E69D76D; Sat, 22 Nov 2008 05:53:35 +1300 (NZDT) Message-ID: <4926E78B.2060200@auckland.ac.nz> Date: Sat, 22 Nov 2008 05:53:31 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: boschie@tik.ee.ethz.ch, trammell@tik.ee.ethz.ch, dressler@informatik.uni-erlangen.de, christoph.sommer@informatik.uni-erlangen.de, muenz@net.in.tum.de, akoba@nttv6.net, lorenzo.peluso@fokus.fraunhofer.de, zseby@fokus.fraunhofer.de, maurizio.molina@dante.org.uk Cc: IPFIX list Subject: [IPFIX] Request for summaries of "Mediator-Framework-based" drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi draft authors: The IPFIX Mediation drafts we're currently considering have informative references to your individual drafts listed below. For example, they are used in the Mediation Problem Statement draft to give clear examples of what Mediators can do. At this week's IPFIX session in Minneapolis, we agreed that it would be better not to have references to "work in Progress" drafts. Instead, we'd like to include brief summaries, say two or three paragraphs, maybe a page each. In order to help the Mediation draft editors, and to make sure that those summaries accurately portray the intent of your drafts, could you please write a brief summary for each of your drafts, end email it to the IPFIX list? Once we have consensus on the Mediaton drafts, the next step for the Working Group will be to consider new WG items. Standards Track drafts on mediators, conforming to the Mediation Framework, will be obvious candidates for new IPFIX work. The drafts we need summaries for are: [I-D.boschi-ipfix-anon] Boschi, E. and B. Trammell, "IP Flow Anonymisation Support", draft-boschi-ipfix-anon-01.txt (work in progress) , July 2008. [I-D.dressler-ipfix-aggregation] Dressler, F., Sommer, C., Muenz, G., and A. Kobayashi, "IPFIX Aggregation", draft-dressler-ipfix-aggregation-05.txt (work in progress) , July 2008. [I-D.peluso-flowselection] Peluso, L., Zseby, T., D'Antonio, S., and M. Molina, "Flow selection Techniques", draft-peluso-flowselection-tech-01.txt (work in progress) , November 2007. Thanks, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 23 09:40:26 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE8F3A693B; Sun, 23 Nov 2008 09:40:26 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EFE3A693B for ; Sun, 23 Nov 2008 09:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dFZhfBiQsQV for ; Sun, 23 Nov 2008 09:40:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9F5173A6912 for ; Sun, 23 Nov 2008 09:40:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1977D2C0004E3; Sun, 23 Nov 2008 18:40:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILbLPbe1D+5t; Sun, 23 Nov 2008 18:40:20 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D0AAA2C000359; Sun, 23 Nov 2008 18:40:10 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Sun, 23 Nov 2008 17:40:11 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Sun, 23 Nov 2008 18:40:10 +0100 Message-ID: In-Reply-To: <49261494.2060206@auckland.ac.nz> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] DRAFT IPFIX meeting minutes Thread-Index: AclNkogOkVKLVA8q2UGzmutU5Cn4xQ== From: "Juergen Quittek" To: "Nevil Brownlee" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] DRAFT IPFIX meeting minutes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1200545211==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1200545211== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3310310410_9690866" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3310310410_9690866 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, There is an update of the minutes mainly based on the notes taken by Ralf Wolter. Please check them at http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt Thanks, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, From ipfix-bounces@ietf.org Sun Nov 23 09:40:26 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE8F3A693B; Sun, 23 Nov 2008 09:40:26 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73EFE3A693B for ; Sun, 23 Nov 2008 09:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dFZhfBiQsQV for ; Sun, 23 Nov 2008 09:40:24 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 9F5173A6912 for ; Sun, 23 Nov 2008 09:40:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1977D2C0004E3; Sun, 23 Nov 2008 18:40:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILbLPbe1D+5t; Sun, 23 Nov 2008 18:40:20 +0100 (CET) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id D0AAA2C000359; Sun, 23 Nov 2008 18:40:10 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Sun, 23 Nov 2008 17:40:11 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Date: Sun, 23 Nov 2008 18:40:10 +0100 Message-ID: In-Reply-To: <49261494.2060206@auckland.ac.nz> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] DRAFT IPFIX meeting minutes Thread-Index: AclNkogOkVKLVA8q2UGzmutU5Cn4xQ== From: "Juergen Quittek" To: "Nevil Brownlee" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] DRAFT IPFIX meeting minutes X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1200545211==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1200545211== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3310310410_9690866" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3310310410_9690866 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, There is an update of the minutes mainly based on the notes taken by Ralf Wolter. Please check them at http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt Thanks, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House1 Victoria Road, London W3 6BL, UK Registered in England 2832014 On 20.11.08 19:53 "Nevil Brownlee" wrote: > Hi all: > > Herewith draft minutes from Wednesday morning's meeting. > Please send me any corrections. > > Cheers, Nevil > > > Minutes of IPFIX Working Group session > 0900, Wed 19 Nov 08 > 33 people attending + 6 more via jabber. > > IANA issues with the psamp-info draft were resolved Tuesday morning, > it's now in the RFC Editor queue. That clears the 'normative > reference needed state of the other three psamp drafts, and four ipfix > drafts in the queue. Also, ongoing discussions with IANA over the > ipfix Information Element registry are now complete; IANA have the IE > Registry online, in XML. > > The IPFIX MIB was presented by Benoit Claise. It is now complete, > Juergen will forward its writeup document to Dan. The psamp wg will > now work on the psamp MIB (the last psamp document), and expect that > to be finished fairly quickly. The psamp wg will then close. > > Brian Trammell presented the File Format draft. That draft, and the > Exporting Types draft are now complete; Nevil will forward their writeup > documents to Dan. > > Benoit presented the Per-SCTP-Stream draft. It is complete, but has a > normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt, a tsvarea > draft specifying SCTP Stream Resets. Since Per-Stream depends on > that, Benoit will work with its author (Randall Stewart) to encourage > tsvarea to accept it as a wg item and get it published as soon as > possible. > > The Config Data Model draft was presented by Benoit. It is complete, > but depends on having its actual data model written in YANG. YANG is > not yet stable, the netconf wg expects to finish it by September 09. > We agreed to keep the IPFIX Config Model draft as is, and wait for > YANG to become stable. We will review that decision next year. > > Kobayashi Atsushi presented the two IPFIX Mediation drafts. These have > both been updated following list discussion; that discussion > continues, but both are nearing completion. Both of them reference > three other drafts that had been discussed in the wg (flow > anonymisation, aggregation, and flow selection techniques) as examples > of IPFIX Mediation. We agreed that the drafts should be revised > further to include brief summaries of the 'examples' drafts, and > quite a few other issues that have arisen on the mailing list. We > believe that those drafts will later reappear as wg work items for > Mediation Intermediate Processes using the Mediation Framework. > > Nevil had circulated a proposed set of milestone changes on the list, > they were discussed and amended. > > Under 'any other business,' it was reported that ippm have considered > specifying some metrics derived from passive measurements - IPFIX would > be a useful source of such data. Alt Morton commented that Passive > Measurements have a low priority in ippm. > > Brian Trammel reported that he and Elisa Boschi had given an IPFIX > tutorial at IMC. > > The meeting closed at 1020; thanks to Ralf Wolter for his meeting > notes. > > ------------------------------------------------------------ > > One-para summary: > > The psamp-info draft is approved, all eight ipfix/psamp drafts can now > appear as RFCs. IANA have published the IPFIX Information Elements > Registry. Three IPFIX drafts are now complete, Nevil and Juergen will > do their writeups and pass them to Dan. The SCTP-per-stream draft is > waiting for a tsvarea document, SCTP Stream Reset. Our Config Model > is complete, we're waiting to see how soon YANG will be stable. The > two IPFIX Mediators drafts are in good shape, but need sections > covering anonymisation, aggregation, and flow selection techniques) as > examples of IPFIX Mediation. --B_3310310410_9690866 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpI, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 On 20.11.08 19:53 "Nevil Brownlee" wrote: > Hi all: > > Herewith draft minutes from Wednesday morning's meeting. > Please send me any corrections. > > Cheers, Nevil > > > Minutes of IPFIX Working Group session > 0900, Wed 19 Nov 08 > 33 people attending + 6 more via jabber. > > IANA issues with the psamp-info draft were resolved Tuesday morning, > it's now in the RFC Editor queue. That clears the 'normative > reference needed state of the other three psamp drafts, and four ipfix > drafts in the queue. Also, ongoing discussions with IANA over the > ipfix Information Element registry are now complete; IANA have the IE > Registry online, in XML. > > The IPFIX MIB was presented by Benoit Claise. It is now complete, > Juergen will forward its writeup document to Dan. The psamp wg will > now work on the psamp MIB (the last psamp document), and expect that > to be finished fairly quickly. The psamp wg will then close. > > Brian Trammell presented the File Format draft. That draft, and the > Exporting Types draft are now complete; Nevil will forward their writeup > documents to Dan. > > Benoit presented the Per-SCTP-Stream draft. It is complete, but has a > normative reference to draft-stewart-tsvwg-sctpstrrst-00.txt, a tsvarea > draft specifying SCTP Stream Resets. Since Per-Stream depends on > that, Benoit will work with its author (Randall Stewart) to encourage > tsvarea to accept it as a wg item and get it published as soon as > possible. > > The Config Data Model draft was presented by Benoit. It is complete, > but depends on having its actual data model written in YANG. YANG is > not yet stable, the netconf wg expects to finish it by September 09. > We agreed to keep the IPFIX Config Model draft as is, and wait for > YANG to become stable. We will review that decision next year. > > Kobayashi Atsushi presented the two IPFIX Mediation drafts. These have > both been updated following list discussion; that discussion > continues, but both are nearing completion. Both of them reference > three other drafts that had been discussed in the wg (flow > anonymisation, aggregation, and flow selection techniques) as examples > of IPFIX Mediation. We agreed that the drafts should be revised > further to include brief summaries of the 'examples' drafts, and > quite a few other issues that have arisen on the mailing list. We > believe that those drafts will later reappear as wg work items for > Mediation Intermediate Processes using the Mediation Framework. > > Nevil had circulated a proposed set of milestone changes on the list, > they were discussed and amended. > > Under 'any other business,' it was reported that ippm have considered > specifying some metrics derived from passive measurements - IPFIX would > be a useful source of such data. Alt Morton commented that Passive > Measurements have a low priority in ippm. > > Brian Trammel reported that he and Elisa Boschi had given an IPFIX > tutorial at IMC. > > The meeting closed at 1020; thanks to Ralf Wolter for his meeting > notes. > > ------------------------------------------------------------ > > One-para summary: > > The psamp-info draft is approved, all eight ipfix/psamp drafts can now > appear as RFCs. IANA have published the IPFIX Information Elements > Registry. Three IPFIX drafts are now complete, Nevil and Juergen will > do their writeups and pass them to Dan. The SCTP-per-stream draft is > waiting for a tsvarea document, SCTP Stream Reset. Our Config Model > is complete, we're waiting to see how soon YANG will be stable. The > two IPFIX Mediators drafts are in good shape, but need sections > covering anonymisation, aggregation, and flow selection techniques) as > examples of IPFIX Mediation. --B_3310310410_9690866 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReWieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSVYXS5IW0fZR4l/CyK IkOfuwzmZjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEx MjMxNzQwMTBaMA0GCSqGSIb3DQEBAQUABIIBAJPZ3zlzpKg+EyqAFUqITWyq/UlimO0HkE0M tVL2Lmd/RFf3V0wt+uVJCKZjjtGv1j4rtAMwoidvDSbGwHh71P3iWeyKMJ8i5sTsEffNgE9v sOB37V692RjISklc7gdIecA3150aBCrW4cnpM+WFEeEcmaBTdtAt26JtJr7CYx34+iPz9YrT rLHVVV2hWvolbyWFkF6PuYETed2OU3tsXxdd5YOAhqcdj8PcGqIajOm+ScBAw3SsZ75CSkRr X5xXCp2KGAjYZL53/ypqIM0GyzozqP/ks+DmKnhDZwESFSuUuIhgouI3DwyQOzTJTZA9+d9E IrNLTIvXIShRpIn7AAM= --B_3310310410_9690866-- --===============1200545211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1200545211==-- +DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSVYXS5IW0fZR4l/CyK IkOfuwzmZjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEx MjMxNzQwMTBaMA0GCSqGSIb3DQEBAQUABIIBAJPZ3zlzpKg+EyqAFUqITWyq/UlimO0HkE0M tVL2Lmd/RFf3V0wt+uVJCKZjjtGv1j4rtAMwoidvDSbGwHh71P3iWeyKMJ8i5sTsEffNgE9v sOB37V692RjISklc7gdIecA3150aBCrW4cnpM+WFEeEcmaBTdtAt26JtJr7CYx34+iPz9YrT rLHVVV2hWvolbyWFkF6PuYETed2OU3tsXxdd5YOAhqcdj8PcGqIajOm+ScBAw3SsZ75CSkRr X5xXCp2KGAjYZL53/ypqIM0GyzozqP/ks+DmKnhDZwESFSuUuIhgouI3DwyQOzTJTZA9+d9E IrNLTIvXIShRpIn7AAM= --B_3310310410_9690866-- --===============1200545211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============1200545211==-- From ipfix-bounces@ietf.org Mon Nov 24 04:41:23 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE9C3A69A3; Mon, 24 Nov 2008 04:41:23 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3843A69A3 for ; Mon, 24 Nov 2008 04:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO00xjk2Li6T for ; Mon, 24 Nov 2008 04:41:21 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 886D03A683A for ; Mon, 24 Nov 2008 04:41:20 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B9A6947B1D; Mon, 24 Nov 2008 13:41:14 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 59CAC46C0; Mon, 24 Nov 2008 13:41:14 +0100 (CET) Message-ID: <492AA0FA.80006@net.in.tum.de> Date: Mon, 24 Nov 2008 13:41:30 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081121050251.0A57.17391CF2@nttv6.net> <4925DD8A.6070306@net.in.tum.de> <20081121232637.9489.17391CF2@nttv6.net> In-Reply-To: <20081121232637.9489.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0939000843==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0939000843== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040803070003090006000006" This is a cryptographically signed message in MIME format. --------------ms040803070003090006000006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Atsushi, Comments inline. Regards, Gerahrd Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> Atsushi Kobayashi wrote: >>>>> Mediator Observation Domain >>>>> >>>>> An IPFIX Mediator does not host the Observation Points and >>>> Why should we disallow IPFIX Mediators which also have native >>>> Observation Points? >>>> >>>>> Observation Domain. The Observation Domain ID in the IPFIX h= eader >>>>> sent by the IPFIX Mediator also indicates the largest set of >>>>> Observation Points from the viewpoint of a Collector. Howeve= r, >>>> This seems to be too generic. The ODID issued by the mediator should= >>>> identify the set of ODs/OPs the exported records belong to. >>> Yes. >>> >>>> It does not always have to be the "largest set of OPs", it can be a = subset. >>>> >>> Certainly, yeFrom ipfix-bounces@ietf.org Mon Nov 24 04:41:23 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AE9C3A69A3; Mon, 24 Nov 2008 04:41:23 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3843A69A3 for ; Mon, 24 Nov 2008 04:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO00xjk2Li6T for ; Mon, 24 Nov 2008 04:41:21 -0800 (PST) Received: from mailout1.informatik.tu-muenchen.de (mailout1.informatik.tu-muenchen.de [131.159.0.12]) by core3.amsl.com (Postfix) with ESMTP id 886D03A683A for ; Mon, 24 Nov 2008 04:41:20 -0800 (PST) Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.informatik.tu-muenchen.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id B9A6947B1D; Mon, 24 Nov 2008 13:41:14 +0100 (CET) Received: from [131.159.14.99] (repulse.net.informatik.tu-muenchen.de [131.159.14.99]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 59CAC46C0; Mon, 24 Nov 2008 13:41:14 +0100 (CET) Message-ID: <492AA0FA.80006@net.in.tum.de> Date: Mon, 24 Nov 2008 13:41:30 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20081121050251.0A57.17391CF2@nttv6.net> <4925DD8A.6070306@net.in.tum.de> <20081121232637.9489.17391CF2@nttv6.net> In-Reply-To: <20081121232637.9489.17391CF2@nttv6.net> X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0939000843==" Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0939000843== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040803070003090006000006" This is a cryptographically signed message in MIME format. --------------ms040803070003090006000006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Atsushi, Comments inline. Regards, Gerahrd Atsushi Kobayashi wrote: > Gerhard Muenz wrote: >> Atsushi Kobayashi wrote: >>>>> Mediator Observation Domain >>>>> >>>>> An IPFIX Mediator does not host the Observation Points and >>>> Why should we disallow IPFIX Mediators which also have native >>>> Observation Points? >>>> >>>>> Observation Domain. The Observation Domain ID in the IPFIX h= eader >>>>> sent by the IPFIX Mediator also indicates the largest set of >>>>> Observation Points from the viewpoint of a Collector. Howeve= r, >>>> This seems to be too generic. The ODID issued by the mediator should= >>>> identify the set of ODs/OPs the exported records belong to. >>> Yes. >>> >>>> It does not always have to be the "largest set of OPs", it can be a = subset. >>>> >>> Certainly, yes. >>> >>>> As an example, the Mediator may be configured not to merge records f= rom >>>> different OPs at all. In this case, we can keep the old OIDs. Or it = may >>>> be configured to merge records from a specific subset of OPs only. >>>> >>> Based on your comments, I think that term "Mediator Observation Domai= n" >>> is unnecessary. Because term "Observation Domain" can be applied to >>> IPFIX Mediator as well, and the meaning is not changed. >>> >>> Is it better to remove this term? >> Not sure. >> >> RFC 5101 says: >> >> Observation Domain >> >> An Observation Domain is the largest set of Observation Points f= or >> which Flow information can be aggregated by a Metering Process. >> ... >=20 > In second thought, I think that ODID issued by Mediator becomes the > largest set of Observation Points from viewpoint of Collector, even if > Mediator merges records from a specific subset of OPs only. >=20 > Simply, I would like to say the following just like RFC5101 mention. > A Mediator Observation Domain indicates the largest set of > Observation Points for which Flow information can be aggregated b= y > a Mediator. >=20 > Is it correct? During second thought, I start to confuse your questions= =2E >=20 >> Observation Domain ID >> >> ... The Observation >> Domain ID SHOULD be 0 when no specific Observation Domain ID is >> relevant for the entire IPFIX Message, for example, when exporti= ng >> the Exporting Process Statistics, or in case of a hierarchy of >> Collectors when aggregated Data Records are exported. >> >> The last sentence already covers the problem of aggregation. >> >> If you are happy with ODID=3D0 for Mediators, then you do not have to >> introduce "Mediator Observation Domain". If you want to use other >> values, maybe it is necessary to introduce a new term here. >=20 > Good point. > I would like to introduce this term. I do not know which way is the best. You should discuss this with other people, e.g. Benoit or Paul. One more remark: the IPFIX Message header contains the ODID as defined in RFC 5101. If you introduced a "Mediator Observation Domain ID" and wanted to use it in the IPFIX Message header, this would be a change of the protocol. Probably, you want to avoid protocol changes. >>>>> this value does not indicate the physical entity of an Origin= al >>>>> Exporter. >>>>> 4.4. IPFIX File Writer/Reader >>>>> >>>>> >>>>> The IPFIX File Writer stores input Flow Records/Packet Reports f= rom >>>>> any process in a storage system. If received Flow Records/Packe= t >>>> It's a "file system". >>>> >>>>> Reports include uninteresting Information Elements, the Modifica= tion >>>>> Function can delete these elements before the IPFIX File Writer >>>>> handles them. Therefore, IPFIX File Writers can accept input fr= om >>>>> any process. In either case, input needs to include the IPFIX h= eader >>>> Remove the whole sentence "Therefore,..." >>>> >>>>> information and the Transport Session Information along with Flo= w >>>>> Records/Packet Reports. >>>> Why does the File Writer require header information and transport >>>> session information as input? >>>> We should not specify additional restrictions for the File Writer he= re. >>>> Also, there are cases where there are no headers and no transport >>>> sessions, e.g. if the writer is linked to a Metering Process. >>>> >>> OK. But, if I'm not mistaken, I think that IPFIX file format includes= >>> session information and Observation Domain ID. >> One IPFIX file corresponds to one transport session. So, there is no >> further information required. The ODID is included in the Message >> headers as usual. >> >=20 > I mean that IPFIX File Writer should receive the incoming IPFIX header > information and incoming Transport Session information in addition to > Data Records in order to comply with IPFIX File format, even if > Intermediate Process send them. The IPFIX File Format specifies which kind of information the Writer should write into the file if it receives data from a Metering Process or Collecting Process: http://tools.ietf.org/html/draft-ietf-ipfix-file-03#section-7.3 At first sight, receiving data from an Intermediate Process is similar to receiving data from a Metering Process. > They do not indicate outgoing IPFIX header information and outgoing > Transport Session information. Therefore, I do not intend to add > special restriction. >=20 > Did my description make you confuse? IPFIX does not standardize the interfaces between functional blocks within an IPFIX device. These interfaces are implementation-specific. An IPFIX device does not even have to follow the proposed architecture but may be structured in a completely different way. IMO, the sentence "input [of the IPFIX File Writer] needs to include the IPFIX header information and the Transport Session Information along with Flow Records/Packet Reports" attempts to specify an interface between two functional blocks, namely Intermediate Process and File Writer, which should be out of scope of IPF= IX. >>> I don't intend to add other restrictions for the File Writer. >>> >>> I will read more IPFIX file format draft.=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040803070003090006000006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyNDEyNDEzMFowIwYJKoZIhvcNAQkEMRYEFJ9MwUmn3wed cQffjs7+IuVPYF2mMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQB/9ANGlWYlZWfwUBnpAwkzFcLKtyumUz8Lakm2/EwZKans2vHEX2Ybyvsy 2WhuM62S62MLFQgsnwqrVGAoZeILfj9323XHSFIO/NaNICvNB/bEqgaDQXve4fuOPpCiIEMf PDd5y9KOhfuAIojz5AImSZzy/ewAXNvPMUDgrg97yQXPit+w9sI8LnOkw52OI/A8+vMP11wc jegDyYyBT2JZE+Ox3EHeami8vtQk1hnsPh1fQ+tJ5X1iLFPikBS+CM8h0c9HkDByoBEjo3hZ 33ejolTgpzYtd/SeRfznvsxHJhW6Juty0nJm9DyrIo0cRLvqXATUGitkWsRlsEDsn8QyAAAA AAAA --------------ms040803070003090006000006-- --===============0939000843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0939000843==-- s. >>> >>>> As an example, the Mediator may be configured not to merge records f= rom >>>> different OPs at all. In this case, we can keep the old OIDs. Or it = may >>>> be configured to merge records from a specific subset of OPs only. >>>> >>> Based on your comments, I think that term "Mediator Observation Domai= n" >>> is unnecessary. Because term "Observation Domain" can be applied to >>> IPFIX Mediator as well, and the meaning is not changed. >>> >>> Is it better to remove this term? >> Not sure. >> >> RFC 5101 says: >> >> Observation Domain >> >> An Observation Domain is the largest set of Observation Points f= or >> which Flow information can be aggregated by a Metering Process. >> ... >=20 > In second thought, I think that ODID issued by Mediator becomes the > largest set of Observation Points from viewpoint of Collector, even if > Mediator merges records from a specific subset of OPs only. >=20 > Simply, I would like to say the following just like RFC5101 mention. > A Mediator Observation Domain indicates the largest set of > Observation Points for which Flow information can be aggregated b= y > a Mediator. >=20 > Is it correct? During second thought, I start to confuse your questions= =2E >=20 >> Observation Domain ID >> >> ... The Observation >> Domain ID SHOULD be 0 when no specific Observation Domain ID is >> relevant for the entire IPFIX Message, for example, when exporti= ng >> the Exporting Process Statistics, or in case of a hierarchy of >> Collectors when aggregated Data Records are exported. >> >> The last sentence already covers the problem of aggregation. >> >> If you are happy with ODID=3D0 for Mediators, then you do not have to >> introduce "Mediator Observation Domain". If you want to use other >> values, maybe it is necessary to introduce a new term here. >=20 > Good point. > I would like to introduce this term. I do not know which way is the best. You should discuss this with other people, e.g. Benoit or Paul. One more remark: the IPFIX Message header contains the ODID as defined in RFC 5101. If you introduced a "Mediator Observation Domain ID" and wanted to use it in the IPFIX Message header, this would be a change of the protocol. Probably, you want to avoid protocol changes. >>>>> this value does not indicate the physical entity of an Origin= al >>>>> Exporter. >>>>> 4.4. IPFIX File Writer/Reader >>>>> >>>>> >>>>> The IPFIX File Writer stores input Flow Records/Packet Reports f= rom >>>>> any process in a storage system. If received Flow Records/Packe= t >>>> It's a "file system". >>>> >>>>> Reports include uninteresting Information Elements, the Modifica= tion >>>>> Function can delete these elements before the IPFIX File Writer >>>>> handles them. Therefore, IPFIX File Writers can accept input fr= om >>>>> any process. In either case, input needs to include the IPFIX h= eader >>>> Remove the whole sentence "Therefore,..." >>>> >>>>> information and the Transport Session Information along with Flo= w >>>>> Records/Packet Reports. >>>> Why does the File Writer require header information and transport >>>> session information as input? >>>> We should not specify additional restrictions for the File Writer he= re. >>>> Also, there are cases where there are no headers and no transport >>>> sessions, e.g. if the writer is linked to a Metering Process. >>>> >>> OK. But, if I'm not mistaken, I think that IPFIX file format includes= >>> session information and Observation Domain ID. >> One IPFIX file corresponds to one transport session. So, there is no >> further information required. The ODID is included in the Message >> headers as usual. >> >=20 > I mean that IPFIX File Writer should receive the incoming IPFIX header > information and incoming Transport Session information in addition to > Data Records in order to comply with IPFIX File format, even if > Intermediate Process send them. The IPFIX File Format specifies which kind of information the Writer should write into the file if it receives data from a Metering Process or Collecting Process: http://tools.ietf.org/html/draft-ietf-ipfix-file-03#section-7.3 At first sight, receiving data from an Intermediate Process is similar to receiving data from a Metering Process. > They do not indicate outgoing IPFIX header information and outgoing > Transport Session information. Therefore, I do not intend to add > special restriction. >=20 > Did my description make you confuse? IPFIX does not standardize the interfaces between functional blocks within an IPFIX device. These interfaces are implementation-specific. An IPFIX device does not even have to follow the proposed architecture but may be structured in a completely different way. IMO, the sentence "input [of the IPFIX File Writer] needs to include the IPFIX header information and the Transport Session Information along with Flow Records/Packet Reports" attempts to specify an interface between two functional blocks, namely Intermediate Process and File Writer, which should be out of scope of IPF= IX. >>> I don't intend to add other restrictions for the File Writer. >>> >>> I will read more IPFIX file format draft.=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms040803070003090006000006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICED9aGsYWkMr+s4zmyODhB+IwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDIxMzE1MTUxN1oX DTA5MDIxMjE1MTUxN1owbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZex/Sq sAxkzTVvKP/YAgkaeXA+ngH59Aa0bbRPsKOWzAndGqty5EKcEzrnKqEJ27qHFvoF/pHp88U2 7SJI/xbqkgWeV2jRaldipZQYlnjYLQcmb4cewIFuGRRSVrm3BquzX38aYazuE4+DVH2Z3a8z n0FcdMXhA1NR2Ma1rh4G7SIeZ+hC7czbvNRPraBliGdQhs8J/6yP/iL8aNYAl9c7CL4ofRj8 Y9orMOV/4vtWTq76/VQUVdbhUMiv0D8aHqI1ZvGskhRRvmITgQRVbbn8N8WTpZ0UCgMDjxPP 9i5IhLfp6oBtsKl4OZ0RXvSLZrbJTkBX3vnEutcyxDvyNgMCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEFBQADgYEAX5SiD6epJePwBjJumOsTF6wzeuZRDLYlN+fOpXwd2C0Yx6i8iIZ9 l/J/nGaE1YpJPfX5oJDE+tOk1vYh2E9ThLOj9kJ3buZmgOCdVu90qtCWhfhli7RCYcJ+G9M3 FCnqbrzI/waPPXGB8/DY1HKgPj5G+oKPUK+GD2aE1Q3PYGowggMVMIICfqADAgECAhA/WhrG FpDK/rOM5sjg4QfiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wODAyMTMxNTE1MTdaFw0wOTAyMTIxNTE1MTdaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGXsf0qrAMZM01byj/2AIJGnlwPp4B +fQGtG20T7CjlswJ3RqrcuRCnBM65yqhCdu6hxb6Bf6R6fPFNu0iSP8W6pIFnldo0WpXYqWU GJZ42C0HJm+HHsCBbhkUUla5twars19/GmGs7hOPg1R9md2vM59BXHTF4QNTUdjGta4eBu0i HmfoQu3M27zUT62gZYhnUIbPCf+sj/4i/GjWAJfXOwi+KH0Y/GPaKzDlf+L7Vk6u+v1UFFXW 4VDIr9A/Gh6iNWbxrJIUUb5iE4EEVW25/DfFk6WdFAoDA48Tz/YuSIS36eqAbbCpeDmdEV70 i2a2yU5AV975xLrXMsQ78jYDAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAF+U og+nqSXj8AYybpjrExesM3rmUQy2JTfnzqV8HdgtGMeovIiGfZfyf5xmhNWKST31+aCQxPrT pNb2IdhPU4Szo/ZCd27mZoDgnVbvdKrQloX4ZYu0QmHCfhvTNxQp6m68yP8Gjz1xgfPw2NRy oD4+RvqCj1Cvhg9mhNUNz2BqMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA/WhrG FpDK/rOM5sjg4QfiMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA4MTEyNDEyNDEzMFowIwYJKoZIhvcNAQkEMRYEFJ9MwUmn3wed cQffjs7+IuVPYF2mMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ P1oaxhaQyv6zjObI4OEH4jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQP1oaxhaQyv6zjObI4OEH4jANBgkqhkiG 9w0BAQEFAASCAQB/9ANGlWYlZWfwUBnpAwkzFcLKtyumUz8Lakm2/EwZKans2vHEX2Ybyvsy 2WhuM62S62MLFQgsnwqrVGAoZeILfj9323XHSFIO/NaNICvNB/bEqgaDQXve4fuOPpCiIEMf PDd5y9KOhfuAIojz5AImSZzy/ewAXNvPMUDgrg97yQXPit+w9sI8LnOkw52OI/A8+vMP11wc jegDyYyBT2JZE+Ox3EHeami8vtQk1hnsPh1fQ+tJ5X1iLFPikBS+CM8h0c9HkDByoBEjo3hZ 33ejolTgpzYtd/SeRfznvsxHJhW6Juty0nJm9DyrIo0cRLvqXATUGitkWsRlsEDsn8QyAAAA AAAA --------------ms040803070003090006000006-- --===============0939000843== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --===============0939000843==-- From lchoquehuancah@alicorp.com.pe Mon Nov 24 11:27:10 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1E43A67EE for ; Mon, 24 Nov 2008 11:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.581 X-Spam-Level: X-Spam-Status: No, score=-31.581 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DITg2PR5P4BT for ; Mon, 24 Nov 2008 11:27:09 -0800 (PST) Received: from i577A6D33.versanet.de (i577A6D33.versanet.de [87.122.109.51]) by core3.amsl.com (Postfix) with SMTP id 5C7213A67DA for ; Mon, 24 Nov 2008 11:27:07 -0800 (PST) To: Subject: Look, ready and wet From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081124192708.5C7213A67DA@core3.amsl.com> Date: Mon, 24 Nov 2008 11:27:07 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From ipfix-bounces@ietf.org Tue Nov 25 01:09:07 2008 Return-Path: X-Original-To: ipfix-archive@lists.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31B33A6ACD; Tue, 25 Nov 2008 01:09:07 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC3D3A68EB for ; Tue, 25 Nov 2008 01:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z316RMApOHzX for ; Tue, 25 Nov 2008 01:09:05 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 66DF43A6ACD for ; Tue, 25 Nov 2008 01:09:04 -0800 (PST) Received: from localhost ([IPv6:2001:fa8:1000:0:e167:b29a:1314:241c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAP98wnU005488; Tue, 25 Nov 2008 18:09:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 25 Nov 2008 18:01:32 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492AA0FA.80006@net.in.tum.de> References: <20081121232637.9489.17391CF2@nttv6.net> <492AA0FA.80006@net.in.tum.de> Message-Id: <20081125174858.6A98.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 25 Nov 2008 18:09:00 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhald, Please see inline. Regards, Atsushi KOBAYASHI On Mon, 24 Nov 2008 13:41:30 +0100 Gerhard Muenz wrote: > > Atsushi, > > Comments inline. > > Regards, > Gerahrd > > Atsushi Kobayashi wrote: > > Gerhard Muenz wrote: > >> Atsushi Kobayashi wrote: > >>>>> Mediator Observation Domain > >>>>> > >>>>> An IPFIX Mediator does not host the Observation Points and > >>>> Why should we disallow IPFIX Mediators which also have native > >>>> Observation Points? > >>>> > >>>>> Observation Domain. The Observation Domain ID in the IPFIX header > >>>>> sent by the IPFIX Mediator also indicates the largest set of > >>>>> Observation Points from the viewpoint of a Collector. However, > >>>> This seems to be too generic. The ODID issued by the mediator should > >>>> identify the set of ODs/OPs the exported records belong to. > >>> Yes. > >>> > >>>> It does not always have to be the "largest set of OPs", it can be a subset. > >>>> > >>> Certainly, yes. > >>> > >>>> As an example, the Mediator may be configured not to merge records from > >>>> different OPs at all. In this case, we can keep the old OIDs. Or it may > >>>> be configured to merge records from a specific subset of OPs only. > >>>> > >>> Based on your comments, I think that term "Mediator Observation Domain" > >>> is unnecessary. Because term "Observation Domain" can be applied to > >>> IPFIX Mediator as well, and the meaning is not changed. > >>> > >>> Is it better to remove this term? > >> Not sure. > >> > >> RFC 5101 says: > >> > >> Observation Domain > >> > >> An Observation Domain is the largest set of Observation Points for > >> which Flow information can be aggregated by a Metering Process. > >> ... > > > > In second thought, I think that ODID issued by Mediator becomes the > > largest set of Observation Points from viewpoint of Collector, even if > > Mediator merges records from a specific subset of OPs only. > > > > Simply, I would like to say the following just like RFC5101 mention. > > A Mediator Observation Domain indicates the largest set of > > Observation Points for which Flow information can be aggregated by > > a Mediator. > > > > Is it correct? During second thought, I start to confuse your questions. > > > >> Observation Domain ID > >> > >> ... The Observation > >> Domain ID SHOULD be 0 when no specific Observation Domain ID is > >> relevant for the entire IPFIX Message, for example, when exporting > >> the Exporting Process Statistics, or in case of a hierarchy of > >> Collectors when aggregated Data Records are exported. > >> > >> The last sentence already covers the problem of aggregation. > >> > >> If you are happy with ODID=0 for Mediators, then you do not have to > >> introduce "Mediator Observation Domain". If you want to use other > >> values, maybe it is necessary to introduce a new term here. > > > > Good point. > > I would like to introduce this term. > > I do not know which way is the best. You should discuss this with other > people, e.g. Benoit or Paul. > > One more remark: the IPFIX Message header contains the ODID as defined > in RFC 5101. If you introduced a "Mediator Observation Domain ID" and > wanted to use it in the IPFIX Message header, this would be a change of > the protocol. Probably, you want to avoid protocol changes. > OK. For next version, I will consult about it with Benoit, Paul and co-authors. > >>>>> this value does not indicate the physical entity of an Original > >>>>> Exporter. > > > >>>>> 4.4. IPFIX File Writer/Reader > >>>>> > >>>>> > >>>>> The IPFIX File Writer stores input Flow Records/Packet Reports from > >>>>> any process in a storage system. If received Flow Records/Packet > >>>> It's a "file system". > >>>> > >>>>> Reports include uninteresting Information Elements, the Modification > >>>>> Function can delete these elements before the IPFIX File Writer > >>>>> handles them. Therefore, IPFIX File Writers can accept input from > >>>>> any process. In either case, input needs to include the IPFIX header > >>>> Remove the whole sentence "Therefore,..." > >>>> > >>>>> information and the Transport Session Information along with Flow > >>>>> Records/Packet Reports. > >>>> Why does the File Writer require header information and transport > >>>> session information as input? > >>>> We should not specify additional restrictions for the File Writer here. > >>>> Also, there are cases where there are no headers and no transport > >>>> sessions, e.g. if the writer is linked to a Metering Process. > >>>> > >>> OK. But, if I'm not mistaken, I think that IPFIX file format includes > >>> session information and Observation Domain ID. > >> One IPFIX file corresponds to one transport session. So, there is no > >> further information required. The ODID is included in the Message > >> headers as usual. > >> > > > > I mean that IPFIX File Writer should receive the incoming IPFIX header > > information and incoming Transport Session information in addition to > > Data Records in order to comply with IPFIX File format, even if > > Intermediate Process send them. > > The IPFIX File Format specifies which kind of information the Writer > should write into the file if it receives data from a Metering Process > or Collecting Process: > http://tools.ietf.org/html/draft-ietf-ipfix-file-03#section-7.3 I have missed out on this section in IPFIX File format draft. > > At first sight, receiving data from an Intermediate Process is similar > to receiving data from a Metering Process. Yes. > > > They do not indicate outgoing IPFIX header information and outgoing > > Transport Session information. Therefore, I do not intend to add > > special restriction. > > > > Did my description make you confuse? > > IPFIX does not standardize the interfaces between functional blocks > within an IPFIX device. These interfaces are implementation-specific. An > IPFIX device does not even have to follow the proposed architecture but > may be structured in a completely different way. > > IMO, the sentence > "input [of the IPFIX File Writer] needs to include the IPFIX header > information and the Transport Session Information along with Flow > Records/Packet Reports" > attempts to specify an interface between two functional blocks, namely > Intermediate Process and File Writer, which should be out of scope of IPFIX. > I understood what you want to say. I will improve the sentense. Thank you very much. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 25 01:09:07 2008 Return-Path: X-Original-To: ipfix-archive@optimus.ietf.org Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31B33A6ACD; Tue, 25 Nov 2008 01:09:07 -0800 (PST) X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC3D3A68EB for ; Tue, 25 Nov 2008 01:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z316RMApOHzX for ; Tue, 25 Nov 2008 01:09:05 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 66DF43A6ACD for ; Tue, 25 Nov 2008 01:09:04 -0800 (PST) Received: from localhost ([IPv6:2001:fa8:1000:0:e167:b29a:1314:241c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id mAP98wnU005488; Tue, 25 Nov 2008 18:09:00 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 25 Nov 2008 18:01:32 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <492AA0FA.80006@net.in.tum.de> References: <20081121232637.9489.17391CF2@nttv6.net> <492AA0FA.80006@net.in.tum.de> Message-Id: <20081125174858.6A98.17391CF2@nttv6.net> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 25 Nov 2008 18:09:00 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Mediator framework: review X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipfix-bounces@ietf.org Errors-To: ipfix-bounces@ietf.org Hi Gerhald, Please see inline. Regards, Atsushi KOBAYASHI On Mon, 24 Nov 2008 13:41:30 +0100 Gerhard Muenz wrote: > > Atsushi, > > Comments inline. > > Regards, > Gerahrd > > Atsushi Kobayashi wrote: > > Gerhard Muenz wrote: > >> Atsushi Kobayashi wrote: > >>>>> Mediator Observation Domain > >>>>> > >>>>> An IPFIX Mediator does not host the Observation Points and > >>>> Why should we disallow IPFIX Mediators which also have native > >>>> Observation Points? > >>>> > >>>>> Observation Domain. The Observation Domain ID in the IPFIX header > >>>>> sent by the IPFIX Mediator also indicates the largest set of > >>>>> Observation Points from the viewpoint of a Collector. However, > >>>> This seems to be too generic. The ODID issued by the mediator should > >>>> identify the set of ODs/OPs the exported records belong to. > >>> Yes. > >>> > >>>> It does not always have to be the "largest set of OPs", it can be a subset. > >>>> > >>> Certainly, yes. > >>> > >>>> As an example, the Mediator may be configured not to merge records from > >>>> different OPs at all. In this case, we can keep the old OIDs. Or it may > >>>> be configured to merge records from a specific subset of OPs only. > >>>> > >>> Based on your comments, I think that term "Mediator Observation Domain" > >>> is unnecessary. Because term "Observation Domain" can be applied to > >>> IPFIX Mediator as well, and the meaning is not changed. > >>> > >>> Is it better to remove this term? > >> Not sure. > >> > >> RFC 5101 says: > >> > >> Observation Domain > >> > >> An Observation Domain is the largest set of Observation Points for > >> which Flow information can be aggregated by a Metering Process. > >> ... > > > > In second thought, I think that ODID issued by Mediator becomes the > > largest set of Observation Points from viewpoint of Collector, even if > > Mediator merges records from a specific subset of OPs only. > > > > Simply, I would like to say the following just like RFC5101 mention. > > A Mediator Observation Domain indicates the largest set of > > Observation Points for which Flow information can be aggregated by > > a Mediator. > > > > Is it correct? During second thought, I start to confuse your questions. > > > >> Observation Domain ID > >> > >> ... The Observation > >> Domain ID SHOULD be 0 when no specific Observation Domain ID is > >> relevant for the entire IPFIX Message, for example, when exporting > >> the Exporting Process Statistics, or in case of a hierarchy of > >> Collectors when aggregated Data Records are exported. > >> > >> The last sentence already covers the problem of aggregation. > >> > >> If you are happy with ODID=0 for Mediators, then you do not have to > >> introduce "Mediator Observation Domain". If you want to use other > >> values, maybe it is necessary to introduce a new term here. > > > > Good point. > > I would like to introduce this term. > > I do not know which way is the best. You should discuss this with other > people, e.g. Benoit or Paul. > > One more remark: the IPFIX Message header contains the ODID as defined > in RFC 5101. If you introduced a "Mediator Observation Domain ID" and > wanted to use it in the IPFIX Message header, this would be a change of > the protocol. Probably, you want to avoid protocol changes. > OK. For next version, I will consult about it with Benoit, Paul and co-authors. > >>>>> this value does not indicate the physical entity of an Original > >>>>> Exporter. > > > >>>>> 4.4. IPFIX File Writer/Reader > >>>>> > >>>>> > >>>>> The IPFIX File Writer stores input Flow Records/Packet Reports from > >>>>> any process in a storage system. If received Flow Records/Packet > >>>> It's a "file system". > >>>> > >>>>> Reports include uninteresting Information Elements, the Modification > >>>>> Function can delete these elements before the IPFIX File Writer > >>>>> handles them. Therefore, IPFIX File Writers can accept input from > >>>>> any process. In either case, input needs to include the IPFIX header > >>>> Remove the whole sentence "Therefore,..." > >>>> > >>>>> information and the Transport Session Information along with Flow > >>>>> Records/Packet Reports. > >>>> Why does the File Writer require header information and transport > >>>> session information as input? > >>>> We should not specify additional restrictions for the File Writer here. > >>>> Also, there are cases where there are no headers and no transport > >>>> sessions, e.g. if the writer is linked to a Metering Process. > >>>> > >>> OK. But, if I'm not mistaken, I think that IPFIX file format includes > >>> session information and Observation Domain ID. > >> One IPFIX file corresponds to one transport session. So, there is no > >> further information required. The ODID is included in the Message > >> headers as usual. > >> > > > > I mean that IPFIX File Writer should receive the incoming IPFIX header > > information and incoming Transport Session information in addition to > > Data Records in order to comply with IPFIX File format, even if > > Intermediate Process send them. > > The IPFIX File Format specifies which kind of information the Writer > should write into the file if it receives data from a Metering Process > or Collecting Process: > http://tools.ietf.org/html/draft-ietf-ipfix-file-03#section-7.3 I have missed out on this section in IPFIX File format draft. > > At first sight, receiving data from an Intermediate Process is similar > to receiving data from a Metering Process. Yes. > > > They do not indicate outgoing IPFIX header information and outgoing > > Transport Session information. Therefore, I do not intend to add > > special restriction. > > > > Did my description make you confuse? > > IPFIX does not standardize the interfaces between functional blocks > within an IPFIX device. These interfaces are implementation-specific. An > IPFIX device does not even have to follow the proposed architecture but > may be structured in a completely different way. > > IMO, the sentence > "input [of the IPFIX File Writer] needs to include the IPFIX header > information and the Transport Session Information along with Flow > Records/Packet Reports" > attempts to specify an interface between two functional blocks, namely > Intermediate Process and File Writer, which should be out of scope of IPFIX. > I understood what you want to say. I will improve the sentense. Thank you very much. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From mail.me@21our.com Wed Nov 26 03:32:26 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0ED23A69B9 for ; Wed, 26 Nov 2008 03:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.674 X-Spam-Level: X-Spam-Status: No, score=-9.674 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02h4wZLUzJnm for ; Wed, 26 Nov 2008 03:32:26 -0800 (PST) Received: from af7.mopera.ne.jp (unknown [86.100.94.233]) by core3.amsl.com (Postfix) with SMTP id B8DCC28C0ED for ; Wed, 26 Nov 2008 03:32:23 -0800 (PST) To: Subject: New Beatles songs found From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126113224.B8DCC28C0ED@core3.amsl.com> Date: Wed, 26 Nov 2008 03:32:23 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From mejia@alphasan.com Fri Nov 28 03:13:34 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F0CE28B23E for ; Fri, 28 Nov 2008 03:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.979 X-Spam-Level: X-Spam-Status: No, score=-27.979 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HELO_IS_SMALL6=0.556, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3HTAqIpn584 for ; Fri, 28 Nov 2008 03:13:34 -0800 (PST) Received: from agefinance.com (unknown [122.162.232.130]) by core3.amsl.com (Postfix) with SMTP id B62EC3A68E4 for ; Fri, 28 Nov 2008 03:13:32 -0800 (PST) To: Subject: take every cutie easily From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081128111332.B62EC3A68E4@core3.amsl.com> Date: Fri, 28 Nov 2008 03:13:32 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From martin.amarante@amher.com.mx Fri Nov 28 11:53:42 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13D723A67C1 for ; Fri, 28 Nov 2008 11:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.619 X-Spam-Level: X-Spam-Status: No, score=-28.619 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, PLING_QUERY=1.39, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owaTMOq-Kw4v for ; Fri, 28 Nov 2008 11:53:41 -0800 (PST) Received: from pc145a152.pogodanet.pl (pc145a152.pogodanet.pl [89.25.145.152]) by core3.amsl.com (Postfix) with SMTP id 8AA023A68E1 for ; Fri, 28 Nov 2008 11:53:37 -0800 (PST) To: Subject: she never cries with you? Change it! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081128195338.8AA023A68E1@core3.amsl.com> Date: Fri, 28 Nov 2008 11:53:37 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From jim.rickey@aglender.net Sat Nov 29 05:18:09 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7573A6ABD for ; Sat, 29 Nov 2008 05:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.609 X-Spam-Level: X-Spam-Status: No, score=-31.609 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK5mslb7Xnto for ; Sat, 29 Nov 2008 05:18:08 -0800 (PST) Received: from amialbacete.com (unknown [89.39.236.64]) by core3.amsl.com (Postfix) with SMTP id 9BB8F3A6AC8 for ; Sat, 29 Nov 2008 05:18:05 -0800 (PST) To: Subject: Greatest Donator From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129131806.9BB8F3A6AC8@core3.amsl.com> Date: Sat, 29 Nov 2008 05:18:05 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From oscar.solano@aeromar.co.cr Sat Nov 29 09:56:16 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2A23A6933 for ; Sat, 29 Nov 2008 09:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -24.299 X-Spam-Level: X-Spam-Status: No, score=-24.299 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MjQlc21UCSm for ; Sat, 29 Nov 2008 09:56:15 -0800 (PST) Received: from adsl-070-148-067-003.sip.clt.bellsouth.net (adsl-070-148-067-003.sip.clt.bellsouth.net [70.148.67.3]) by core3.amsl.com (Postfix) with SMTP id 4F3FD3A6823 for ; Sat, 29 Nov 2008 09:56:13 -0800 (PST) To: Subject: Agent's escort was killed From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129175614.4F3FD3A6823@core3.amsl.com> Date: Sat, 29 Nov 2008 09:56:13 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From narcissus7@amada.com Sat Nov 29 22:21:42 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DBA13A6806 for ; Sat, 29 Nov 2008 22:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.202 X-Spam-Level: X-Spam-Status: No, score=-20.202 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgaDEGhNqGRu for ; Sat, 29 Nov 2008 22:21:36 -0800 (PST) Received: from VDSL-130-13-161-183.PHNX.QWEST.NET (VDSL-130-13-161-183.PHNX.QWEST.NET [130.13.161.183]) by core3.amsl.com (Postfix) with SMTP id 828983A686B for ; Sat, 29 Nov 2008 22:21:34 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081130062135.828983A686B@core3.amsl.com> Date: Sat, 29 Nov 2008 22:21:34 -0800 (PST) Click here to view as a webpage. From jlrivers@accessvt.com Sun Nov 30 12:42:26 2008 Return-Path: X-Original-To: ietfarch-ipfix-archive@core3.amsl.com Delivered-To: ietfarch-ipfix-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963253A6BD8 for ; Sun, 30 Nov 2008 12:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.827 X-Spam-Level: X-Spam-Status: No, score=-79.827 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyi7O0uE39E4 for ; Sun, 30 Nov 2008 12:42:25 -0800 (PST) Received: from alert.bankofamerica.com (unknown [217.132.38.215]) by core3.amsl.com (Postfix) with SMTP id C0CC63A6A43 for ; Sun, 30 Nov 2008 12:42:24 -0800 (PST) To: Subject: Smokeless tobacco - true and lies From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081130204224.C0CC63A6A43@core3.amsl.com> Date: Sun, 30 Nov 2008 12:42:24 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052