From root@core3.amsl.com Tue Jun 9 06:30:01 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5BB363A68A9; Tue, 9 Jun 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090609133001.5BB363A68A9@core3.amsl.com> Date: Tue, 9 Jun 2009 06:30:01 -0700 (PDT) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-exporting-type-05.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Exporting Type Information for IPFIX Information Elements Author(s) : E. Boschi, et al. Filename : draft-ietf-ipfix-exporting-type-05.txt Pages : 20 Date : 2009-06-09 This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage and analysis, 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, and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-exporting-type-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-exporting-type-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-09061656.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Jun 9 07:26:59 2009 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 196EC3A6CD5; Tue, 9 Jun 2009 07:26:58 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090609142659.196EC3A6CD5@core3.amsl.com> Date: Tue, 9 Jun 2009 07:26:59 -0700 (PDT) Cc: Internet Architecture Board , ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Exporting Type Information for IPFIX Information Elements' 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: , X-List-Received-Date: Tue, 09 Jun 2009 14:26:59 -0000 The IESG has approved the following document: - 'Exporting Type Information for IPFIX Information Elements ' as a Proposed Standard This document is the product of the IP Flow Information Export 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-ipfix-exporting-type-05.txt 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. Personnel Nevil Brownlee is the Document Shepherd. Dan Romascanu is the Responsible Area Director. Nevil Brownlee is the IANA Expert Reviewer. From dromasca@avaya.com Tue Jun 9 07:51:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BBB73A6877 for ; Tue, 9 Jun 2009 07:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 BPDO-6IA8HqX for ; Tue, 9 Jun 2009 07:51:23 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 56F2A3A6825 for ; Tue, 9 Jun 2009 07:51:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,332,1241409600"; d="scan'208";a="163760371" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 09 Jun 2009 10:51:28 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 09 Jun 2009 10:51:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Jun 2009 16:51:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Protocol Action: 'Exporting Type Information for IPFIX Information Elements' to Proposed Standard Thread-Index: AcnpDoXeU7YxgXFkQq6I3nCcE7lWJgAAvlfQ From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] FW: Protocol Action: 'Exporting Type Information for IPFIX Information Elements' 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: , X-List-Received-Date: Tue, 09 Jun 2009 14:51:24 -0000 This document was approved by the IESG as Proposed Standard. Thanks and congratulations to the editors, the chairs and the whole Working Group.=20 Dan -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, June 09, 2009 5:27 PM To: IETF-Announce Cc: Internet Architecture Board; ipfix chair; ipfix mailing list; RFC Editor Subject: [IPFIX] Protocol Action: 'Exporting Type Information for IPFIX Information Elements' to Proposed Standard The IESG has approved the following document: - 'Exporting Type Information for IPFIX Information Elements ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group.=20 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-ipfix-exporting-type-05.t xt 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. Personnel Nevil Brownlee is the Document Shepherd. Dan Romascanu is the Responsible Area Director. Nevil Brownlee is the IANA Expert Reviewer. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Wed Jun 10 02:25:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81323A67A4 for ; Wed, 10 Jun 2009 02:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 kcaPW8DhLCVo for ; Wed, 10 Jun 2009 02:25:08 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id EABE83A6E0F for ; Wed, 10 Jun 2009 02:25:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,339,1241409600"; d="scan'208";a="148151510" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2009 05:25:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jun 2009 05:25:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 11:25:11 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnpRYT1lltupJoVRoye5fl5+wRurwAZ6L4Q From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 09:25:13 -0000 I threw a comment in this discussion that IPFIX may be a technology to be considered for session recording.=20 Any opinions or suggestions on this idea?=20 Dan -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Wednesday, June 10, 2009 12:02 AM To: dispatch@ietf.org Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan Subject: [dispatch] Session recording in SIP Hi: I realize that the deadline for charter proposals was yesterday, but I hope that it is not too late to submit one more. A few interested people (Hadriel Kaplan, Dan Wing, Rajnish Jain, Leon Portman, Andrew Hutton and I) have been interested in RTP session recording in SIP. The requirement draft will be released shortly. We would like to request agenda time in dispatch to propose the formation of a new working group to define protocol extensions and an architecture for RTP recording. Session recording in SIP Mailing Lists: TBD Chairs: TBD Area Directorate: Real Time Applications (RAI) Purpose: Session recording is a critical operational requirement in many businesses, especially where voice is used as a medium for commerce and customer support. A prime example where voice is used for trade is the financial industry. The call recording requirements in this industry are quite stringent. The recorded calls are used for dispute resolution and regulatory compliance. Other businesses such as customer support call centers typically employ call recording for quality control or business analytics. Depending on the country and its regulatory requirements, financial trading floors typically must record all calls. The recorded media content must be an exact copy of the actual conversation (i.e. clipping and loss of media are unacceptable). Some deployments and regulations require that calls be aborted or rejected if the recording device is unavailable. This group will specify requirements for a SIP based protocol interface between a communications system and a recorder. The Communications System is responsible for establishing media sessions where the actual business is conducted. The Recorder is the sink of the recorded media. The recorded sessions can be of any kind such as voice, video and instant messaging. A recorded session is typically comprised of actual media content and the call metadata. The call metadata allows recording archives to be searched and filtered at a later time. The conveyance of call metadata from the communications system to the recorder is outside the scope of this document. This group will only looks into active recording, where the recorded system purposefully streams media to a recording device. Passive recording, where a recording device detects media directly from the network, is outside the scope of this document. In addition, lawful intercept is outside the scope of the group. Proposed deliverables: 1) Requirements document; 2) Solutions document, including reference architecture. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From j.schoenwaelder@jacobs-university.de Wed Jun 10 02:50:18 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14D13A6E28 for ; Wed, 10 Jun 2009 02:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30If38CgMUk4 for ; Wed, 10 Jun 2009 02:50:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ECE1B3A6879 for ; Wed, 10 Jun 2009 02:50:17 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BB98C001E; Wed, 10 Jun 2009 11:50:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AQijqv6no0Kp; Wed, 10 Jun 2009 11:50:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA36CC000A; Wed, 10 Jun 2009 11:50:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A9DD6B36553; Wed, 10 Jun 2009 11:50:21 +0200 (CEST) Date: Wed, 10 Jun 2009 11:50:21 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090610095021.GA5866@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 09:50:19 -0000 On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote: > I threw a comment in this discussion that IPFIX may be a technology to > be considered for session recording. > > Any opinions or suggestions on this idea? They want to record complete media streams. IPFIX supports the export of flow summary records. I do not see a relation here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 10 03:49:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3836C3A6B9C for ; Wed, 10 Jun 2009 03:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 o4Qb6Rg+KHVE for ; Wed, 10 Jun 2009 03:49:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BCB613A68FE for ; Wed, 10 Jun 2009 03:49:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,340,1241409600"; d="scan'208";a="148157704" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jun 2009 06:49:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 10 Jun 2009 06:49:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 12:49:07 +0200 Message-ID: In-Reply-To: <20090610095021.GA5866@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] FW: [dispatch] Session recording in SIP Thread-Index: AcnpsOLO/FaycithTMCxtMfH0VFgkQAB/Ftw References: <20090610095021.GA5866@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 10:49:11 -0000 You are correct about media recording. A session is however composed out of media and signaling (sometimes going on different paths). For the signaling part IPFIX may be sufficient. Dan =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, June 10, 2009 12:50 PM > To: Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group > Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP >=20 > On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote: >=20 > > I threw a comment in this discussion that IPFIX may be a=20 > technology to=20 > > be considered for session recording. > >=20 > > Any opinions or suggestions on this idea?=20 >=20 > They want to record complete media streams. IPFIX supports=20 > the export of flow summary records. I do not see a relation here. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From akoba@nttv6.net Wed Jun 10 05:42:40 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E45E3A67FB for ; Wed, 10 Jun 2009 05:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 PU8u4egKqaqL for ; Wed, 10 Jun 2009 05:42:35 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B9E0E3A6ADA for ; Wed, 10 Jun 2009 05:42:33 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:cc40:6328:3285:458]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5ACgZuC072416; Wed, 10 Jun 2009 21:42:38 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 10 Jun 2009 21:39:41 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A1BE50E.6040407@net.in.tum.de> References: <4A1BE50E.6040407@net.in.tum.de> Message-Id: <20090610211008.6E53.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 10 Jun 2009 21:42:38 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:42:40 -0000 Dear Gerhard, and co-authors, Sorry for late reply. I really appreciate your detailed review. I put my thought for your comments. On Tue, 26 May 2009 14:48:14 +0200 Gerhard Muenz wrote: > > Dear Atsushi, all, > > Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03 > > I think the purpose of the document is much clearer now. > > Apart from the terminology and the introduction, which should be > rewritten, the document is in a good shape. > > In my opinion, the terminology related to Mediation must be rethought > another time before publishing this problem statement as an RFC. > The current terminology section defines the following terms: > > *IPFIX Mediation* > = a function > > *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* > = specific types of IPFIX Mediation > Do you suggest that they are a specific type of device? e.g. IPFIX Proxy An IPFIX Proxy is a type of IPFIX Mediator that relays incoming ^^^^^^^^ Transport Sessions to one or multiple Collectors. Your points are reasonable for me, the further discussion with co-authors is needed to address it. > *IPFIX Mediator* > = devices that implements IPFIX Mediation > If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are defined as the devices, I think that the following issues can be solved. > This terminology has several flaws: > - On the one hand, you have troubles to distinguish between IPFIX > Mediation implemented at an "Original Exporter" and IPFIX Mediation > implemented at a "separate IPFIX Mediator/Concentrator/...". > - On the other hand, the terms do not fit into the current terminology > scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we > talk about the instantiation of a specific function. I will add "XXX Process" terms in framework draft rather than problem statement. It seems better that the problem statement draft does not include the "XXX Process" terms illustrating the implementation. > - Finally, the definition of IPFIX Concentrator does not correspond to > the usage of this term in RFC3917. There, a Concentrator is a device, > not a function. > > I like the approach that has been chosen by PSAMP. There, we distinguish > between "Selectors" (which are abstract selection functions) and > "Selection Processes" (which are instantiations of Selectors). Selection > Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest > to apply this approach to Mediation as well. > > In the case of Mediation, we would have abstract Mediation Functions > (anonymization, aggregation, sampling, proxy, distribution). These would > be instantiated in a Mediation Process. A Mediation Process can then be > part of an Exporter (Original Exporter), Collector, or Mediator. Yes. We can describe the your suggestion as "Intermediate Process" in framework draft. > Regards, > Gerhard > > > Abstract > > > > Flow-based measurement is a popular method for various network > > monitoring usages. The sharing of flow-based information for > > monitoring applications having different requirements raises some > > open issues in terms of measurement system scalability, flow-based > > measurement flexibility, and export reliability that IPFIX Mediation > > may help resolve. IPFIX Mediation covers two classes of mediation: > > context mediation for traffic data and transport mediation for > > content mediation > > > transport protocols. This document describes the IPFIX Mediation > > applicability examples, along with some problems that network > > administrators have been facing. > > > 1. Introduction > > > > While the IPFIX requirements defined in [RFC3917] mention an > > intermediate function, such as an IPFIX Proxy or an IPFIX > > Concentrator, there are no documents defining the function called > > IPFIX Mediation. IPFIX Mediation is a generic function that covers > > the manipulation of IPFIX Flow Records, PSAMP Packet Reports, entire > > IPFIX Messages, or their transmission. This document describes > > general problems, applicability examples, and defines the terminology > > (IPFIX Proxy, Concentrator, etc.) for referring to different use > > cases for IPFIX Mediation. Furthermore, some specific problems > > related to the IPFIX protocol [RFC5101] when applying IPFIX Mediation > > are addressed. > > The only motivation for IPFIX Mediation given in this introduction is > that the term has not yet defined in any document. This cannot be a > reason for publishing an RFC ;) Yes, indeed. > > I would like to see a much stronger motivation elaborating the arguments > and problems of the abstract. > I will improve it. > > This document is structured as follows: section 2 describes the > > terminology used in this document, section 3 gives an IPFIX/PSAMP > > document overview, section 4 introduces general problems related to > > flow-based measurement, section 5 describes some applicability > > examples where IPFIX Mediations would be beneficial, and, finally, > > section 6 describes some problems an IPFIX Mediation implementation > > might face. > > > > 2. Terminology and Definition > > Definitions > > > The terms in this section are in line with those in the IPFIX > > Protocol specifications [RFC5101] and the PSAMP specification > > document [RFC5476]. The terms Observation Point, Observation Domain, > > Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > > IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > > Process, Transport Session, Information Element, and Template > > Withdrawal Message, are defined in the IPFIX protocol specifications > > [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > > Device, and Configured Selection Fraction are defined in the PSAMP > > specification document [RFC5476]. Furthermore, new terminology to be > > used in the context of IPFIX Mediation is defined in this section. > > All these terms have an initial capital letter in this document. > > > > While IPFIX Mediation can process both Flow Records and Packet > > Reports, this document prefers the more generic "Data Record" term as > > this is a more generic term, unless the reference to the IPFIX Flow > > Record or PSAMP Packet Report is required. > > this is a more generic term, unless the reference to the IPFIX Flow > > Record or PSAMP Packet Report is required. > > better: > "IPFIX Mediation can process IPFIX Flow Records, PSAMP Packet Reports, > and Data Records defined by Options Templates. In this document, we use > the generic term "Data Record" for all of these unless an explicit > distinction is required." > Thanks. > > IPFIX Mediation > > > > IPFIX Mediation is a generic function that covers the manipulation > > remove "generic" ? > > > of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX > > Messages, or their transmission. The IPFIX Mediation offers one > > Could be read as "covers the transmission of...", which would make an > Exporting Process a Mediation function. > > Also, you sentence does not include "Options Data Records" (I put this > in quotes because it is not an official term). Yes, indeed. > > maybe: > "...covers the manipulation of the content and transmission of Data > Records and IPFIX Messages." Fine. > > > or multiple of the following capabilities: > > > > * content mediation that changes Flow Records/Packet Reports > > information > > > > + aggregating Flow Records/Packet Reports based on a new set > > of Flow Key fields > > > > + correlating a set of Flow Records/Packet Reports > > > > + filtering and selecting Flow Records/Packet Reports > > > > + modifying Flow Records/Packet Reports, including: > > > > - changing the value of specified Information Elements > > > > - adding new Information Elements by deriving further Flow > > or packet properties from existing fields (for example: > > calculating new metrics or new counters) > > > > - deleting specified Information Elements > > in the whole definition: > s/Flow Records\/Packet Reports/Data Records > > > * transport mediation > > > > + changing the transport protocol that carries IPFIX Messages > > > > + rerouting entire IPFIX Messages to an appropriate Collecting > > Process > > rerouting => relaying ? > Yes. > > + replicating Flow Records/Packet Reports (or the entire IPFIX > > Messages) > > s/Flow Records\/Packet Reports/Data Records > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that implements one or more > > IPFIX Mediation capabilities. Examples are devices such as > > routers, switches, network management systems (NMS), etc. > > > > Original Exporter > > > > An Original Exporter is an IPFIX Device that hosts the Observation > > Points where the metered IP packets are observed. > > > > IPFIX Proxy > > > > An IPFIX Proxy is a type of IPFIX Mediation that relays incoming > > remove "An" > > > Transport Sessions to one or multiple Collectors. The protocols > > used at the input and the output can be different, which implies > > that IPFIX Messages, Data Records, and Template Records need to be > > encoded, e.g., for converting from a legacy protocol to IPFIX. An > > IPFIX Proxy is not implemented on the Original Exporter, but as a > > separate Mediator. > > I would remove the last sentence. Otherwise, you need to explain what > you mean by "separate Mediator". > > > IPFIX Concentrator > > > > An IPFIX Concentrator is a type of IPFIX Mediation that receives > > Flow Records/Packet Reports, correlates them, aggregates them, or > > s/Flow Records\/Packet Reports/Data Records > > > modifies them, then exports the new Data Records. > > > > IPFIX Distributor > > > > An IPFIX Distributor is a type of IPFIX Mediation that distributes > > Data Records to one or multiple IPFIX Collectors. The decision as > > to which IPFIX Collector a Data Record is exported can be > > determined by filtering certain field values or other properties > > derived from the Data Record. > > > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is a type of IPFIX Mediation that > > screens out parts of input Flow Records/Packet Reports according > > s/Flow Records\/Packet Reports/Data Records > > > to configured policies. It can thus, for example, hide the > > network topology information or customers' IP addresses. > > > > 3. IPFIX/PSAMP Documents Overview > > > > 3.1. IPFIX Documents Overview > > > > The IPFIX protocol [RFC5101] provides network administrators with > > access to IP flow information. The architecture for the export of > > measured IP flow information out of an IPFIX Exporting Process to a > > Collecting Process is defined in [RFC5470], per the requirements > > defined in [RFC3917]. The IPFIX protocol [RFC5101] specifies how > > IPFIX Data Records and Templates are carried via a number of > > transport protocols from IPFIX Exporting Processes to IPFIX > > Collecting Processes. IPFIX has a formal description of IPFIX > > Information Elements, their names, types, and additional semantic > > information, as specified in [RFC5102]. [I-D.ietf-ipfix-mib] > > specifies the IPFIX Management Information Base. Finally, [RFC5472] > > describes what types of applications can use the IPFIX protocol and > > how they can use the information provided. It furthermore shows how > > the IPFIX framework relates to other architectures and frameworks. > > The storage of IPFIX Messages in a file is specified in > > [I-D.ietf-ipfix-file]. > > > > 3.2. PSAMP Documents Overview > > > > The framework for packet selection and reporting [RFC5474] enables > > network elements to select subsets of packets by statistical and > > other methods and to export a stream of reports on the selected > > packets to a Collector. The set of packet selection techniques > > (Sampling, Filtering, and Hashing) standardized by PSAMP are > > described in [RFC5475]. The PSAMP protocol [RFC5476] specifies the > > export of packet information from a PSAMP Exporting Process to a > > Collector. Like IPFIX, PSAMP has a formal description of its > > Information Elements, their names, types and additional semantic > > information. The PSAMP information model is defined in [RFC5477]. > > [I-D.ietf-psamp-mib] describes the PSAMP Management Information Base. > > > > 4. Problem Statement > > > > Network administrators generally face the problems of measurement > > system scalability, flow-based measurement flexibility, and export > > reliability, even if some techniques, such as Sampling, Filtering, > > Data Records aggregation and export replication, have already been > > developed. The problems consist of optimizing the resources of the > > measurement system while pursuing appropriate conditions: data > > pursuing => fulfilling ? Yes. > > > accuracy, flow granularity, and export reliability. These conditions > > depend on two factors. > > > > o measurement systems capacity: > > This consists of the bandwidth of the management network, the > > storage capacity, and the performances of the collecting devices > > and exporting devices. > > > > o applications requirements: > > Different applications, such as traffic engineering, detecting > > anomaly traffic, and accounting, etc., impose different Flow > > traffic anomalies > > > Record granularity, and data accuracy. > > > > The recent continued IP traffic growth has been overwhelming the > > "The sustained growth of IP traffic..." ? > > > measurement system capacity, and multi-purposing applications, along > > multi-purpose? > > Yet, it is not clear to me what you mean. > I means that implementation of multiple traffic measurements, such as QoS measurement and traffic engineering, have been contributing to a complex situation, and executing it with the heterogeneous environments also results in further more complex. > > with the heterogeneous environments, have further been contributing > > to a complex situation. The following sub-sections explain different > > problems in more details. > > > > 4.1. Coping with IP Traffic Growth > > > > Enterprise or service provider networks already have multiple 10 Gb/s > > links, their total traffic exceeding 100 Gb/s. In the near future, > > broadband users' traffic will increase by approximately 40% every > > year according to [TRAFGRW]. When operators monitor traffic of 500 > > Gb/s with a 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. > > > > To deal with this problem, current data reduction techniques, such as > > Sampling, Filtering, Data Records aggregation have been generally > > For me, "aggregation" refers to the semantic level of exported > information. Therefore, I would call it "flow aggregation" instead of > "Data Record aggregation". Does the flow in "flow aggregation" indicate general 7-tuple flow in NetFlow? It needs the distinction between flow in NetFlow and Flow in IPFIX, since the Flow term in IPFIX covers an aggregated Flow. > > > implemented on Exporters. Note that Sampling technique leads to > > Sampling technique => packet sampling ? > Yes. > > potential loss of small Flows. With both Sampling and aggregation > > techniques, administrators might no longer be able to investigate > > very granular traffic change and anomaly detection, both of which can > > "...able to detect and investigate subtle traffic changes and anomalies > as this requires detailed flow information." ? > Yes. > > currently be detected. With Filtering, only a subset of the Flow > > Data Records > > > Records are exported. > > > > Considering the potential drawbacks of Sampling, Filtering, and Data > > Records aggregation, there is a need for a large-scale collecting > > infrastructure that does not rely on data reduction techniques. > > > > 4.2. Coping with Multipurpose Traffic Measurement > > > > A set of conditions (flow granularity and data accuracy) may meet the > > "conditions" does not seem to be an appropriate word. > > > requirements of some applications, such as traffic engineering, but > > may not meet the requirements of other applications, such as > > accounting, QoS performance, or even security. Therefore, with a > > single set of conditions, multipurpose traffic measurements cannot be > > accomplished. > > > > To cope with the issue, an Exporter needs to export traffic data with > > strictest condition (fine flow granularity and high data accuracy) > > required by the set of applications. However, this implies an > > increased load on both the Exporter and Collector. > > I would change the whole section to something like: > > "Different monitoring applications, such as ..., impose different > requirements on the monitoring infrastructure. Some of them require > traffic monitoring at a flow level while others need information about > individual packets or just flow aggregates. > > To fulfill these divers requirements, an Exporter would need to perform > various complex metering tasks in parallel, which is a problem due to > limited resources. Hence, it can be advantageous to run the Exporter > with a much simpler setup and to perform appropriate post-processing of > the exported Data Records at a later stage." > Thanks. It become more clear and concise. > > 4.3. Coping with Heterogeneous Environments > > > > Network administrators use IPFIX Devices and PSAMP Devices from > > various vendors, various software versions, various device types > > (router, switch, or probe) in a single network domain. Even legacy > > flow export protocols are still deployed in current network. This > > heterogeneous environment leads to differences in Metering Process > > capability, Exporting Process capacity (export rate, cache memory, > > capabilities > > > etc.), and data format. For example, probes and switches cannot > > retrieve packet property information from a route table. > > Do you mean AS information? > Yes. "For example, probes and switches cannot retrieve some Derived Packet Properties in [RFC5102] from a route table." > > To deal with this problem, the collecting infrastructure needs to > > absorb the differences. However, equipping all collecting devices > > absorb => mediate? > Yes. > > with this absorption function is difficult. > > > > 4.4. Summary > > > > In optimizing the resources of a measurement system, it is important > > to use traffic data reduction techniques at the possible initial > > "at the possible initial phase" => "as early as possible" > Yes. "it is important to use traffic data reduction techniques as early as possible , e.g., at the Exporter." > > phase, e.g., at the Exporter. However, this implementation is made > > difficult by heterogeneous environment of exporting devices. > > > > This implies that a new Mediation functional block is required in > > Mediation function > > > typical Exporter-Collector architectures. Based on some > > applicability examples, the next section shows the limitation of the > > typical Exporter-Collector architecture model and the IPFIX Mediation > > benefits. > > > > 5. Mediation Applicability Examples > > > > 5.1. Adjusting Flow Granularity > > > > The simplest types of Flows are those comprised of packets all having > > a fixed IP-quintuple of protocol, source and destination IP > > addresses, and source and destination port numbers. However, a > > shorter set of Flow Keys, such as a triple, a double, or a single > > Flow Key, (for example network prefix, peering AS number, or BGP > > Next-Hop fields), creates more aggregated Flow Records. This is > > especially useful for measuring traffic exchange in an entire network > > domain and for easily adjusting the performance of Exporters and > > Collectors. > > > > Implementation analysis: > > > > Implementations for this case depend on where Flow granularity is > > adjusted. More suitable implementations use configurable Metering > > Processes in Original Exporters. The cache in the Metering > > Process can specify its own set of Flow Keys and extra fields. > > The Original Exporter thus creates directly aggregated Flow > > Records. > > > > In the case where the Original Exporter contains a Metering > > Process that creates fixed tuple Flow Records (no possibility to > > change the Flow Keys), an IPFIX Concentrator can adjust the Flow > > Keys by aggregation Flow Records. Even if the case where the > > Original Exporter contains a Metering Process for which the Flow > > Keys can be configured, an IPFIX Concentrator can further > > aggregate the Flow Records. > > > > 5.2. Hierarchical Collecting Infrastructure > > > > The increase of IPFIX Exporters, the increase of the traffic over > > over => in ? > Yes. "over large-scale networks" can be removed, since the traffic growth occurs in any networks. > > large-scale networks, and the variety of treatments expected to be > > performed over the Data Records is more and more difficult to handle > > within a single Collector. Hence to increase the collecting (e.g. > > the bandwidth capacity) and processing capacity must be distributed > > Something is missing in this sentence. What about: > "Hence to increase the collecting (e.g., the bandwidth capacity) and > processing capacity, distributed Collectors must be deployed." > Fine. > > over several IPFIX entities. As a possible approach, a hierarchical > > structure is useful for increasing the measurement systems capacity, > > both in export bandwidth capacity and in collecting capacity. > > > > Implementation analysis: > > > > To cope with the increase of IPFIX Exporters and traffic, one > > possible implementation uses IPFIX Concentrators to build a > > hierarchical collection system. To cope with the variety of > > treatments, one possible implementation uses IPFIX Distributors to > > build a distributed collection system. More specific cases are > > described in section 5.9. > > > > 5.3. Correlation for Data Records > > > > The correlation amongst Data Records or between Data record and meta > > Record > > > data provides new metrics or information, including the following. > > > > o One-to-one correlation between Data Records > > > > * One way delay and packet arrival interval time etc. One way > > packet arrival interval time => packet inter-arrival time ? > Yes. > > delay from the correlation of Packet Reports from different > > PSAMP Packet Reports? > Yes. > > Exporters along a specific path. > > > > * Treatment from the correlation of Data Records with the same > > IPFIX Flow Records? > In that case, both of IPFIX Flow Records and PSAMP Packet Reports can be applied. > > Flow Key(s) observed at incoming/outgoing interfaces. Examples > > are the rate-limiting ratio, the compression ratio, the > > optimization ratio, etc. > > At the recent TMA workshop, it was proposed to correlate Flow Records > from ingress and egress routers to determine packet loss on the path > (A. Friedl et al.: "Realistic Passive Packet Loss Measurement for > High-Speed Networks") > > This could be another use-case for correlating Flow Records. > It is interesting. It can be considered in future topics about mediation. > > o Correlation amongst Data Records > > > > Average/maximum/minimum values from correlating multiple Data > > Records. Examples are the average/maximum/minimum packets of > > number of packets of the measured Flows > > > Flow, the average/maximum/minimum one way delay, the average/ > > maximum/minimum packet loss, etc. > > number of lost packets > > > o Correlation between Data Record and other meta data > > > > Examples are some BGP attributes associated with Data Record by > > looking up routing table. > > the routing table ? > Yes. > > Implementation analysis: > > > > One possible implementation for the case uses an IPFIX > > this case > > > Concentrator located between the Metering Processes and Exporting > > Processes on the Original Exporter, or alternatively a separate > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. > > > > 5.4. Time Composition > > > > Time composition is defined as the aggregation of consecutive Data > > in this case: IPFIX Flow Records > Aggregation (including the Time composition) can be applied to both of input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this case keeps "Data Records". > > Records with identical Flow Keys. It leads to the same output as > > setting a longer active interval timer on Original Exporters with one > > advantage: the creation of new metrics such as average, maximum and > > minimum values from Flow Records with a shorter time interval enables > > administrators to keep track of changes that might have happened > > during the time interval. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > Processes on the Original Exporter, or alternatively as a separate > > remove "as" > > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. > > > > 5.5. Spatial Composition > > > > Spatial composition is defined as the aggregation of Data Records in > > a set of Observation Points within an Observation Domain, across > > multiple Observation Domains from a single Exporter, or even across > > multiple Exporters. The spatial composition is divided into four > > types. > > > > o Case 1: Spatial Composition within one Observation Domain > > > > For example, in the case where a link aggregation exists, Data > > Records observed at physical interfaces belonging to the same > > You do not "observe" Data Records. Maybe: > "...Data Records with information measured at..." > Thanks. > > trunk can be merged. > > > > o Case 2: Spatial Composition across Observation Domains, but within > > a single Exporter > > > > For example, in the case where a link aggregation exists, Data > > Records observed at physical interfaces belonging to a same trunk > > "...Data Records with information measured at..." > > > grouping beyond the line interface module can be merged. > > > > o Case 3: Spatial Composition across Exporters > > > > Data Records observed within an administrative domain, such as the > > "...Data Records with information measured at..." > > > west area and east area of an ISP network, can be merged. > > > > o Case 4: Spatial Composition across administrative domains > > > > Data Records observed across administrative domains, such as > > "...Data Records with information measured at..." > > > across different customer networks or different ISP networks, can > > be merged. > > > > Implementation analysis: > > > > One possible implementation for the case 1 and 2 uses an IPFIX > > cases > > > Concentrator located between the Metering Processes and Exporting > > Processes on the Original Exporter. A separate IPFIX Concentrator > > located between the Original Exporters and IPFIX Collector is a > > valid solution for the case 1, 2, 3, and 4. > > cases > > > 5.6. Data Record Anonymization > > > > IPFIX exports across administrative domains can be used to measure > > traffic for wide-area traffic engineering or to analyze Internet > > traffic trends, as described in the Spatial Composition across > > as described in the previous subsection on "spacial composition across > administrative domaines". > Yes. > > administrative domains in the previous subsection. > > In such case, administrators need to adhere to privacy protection > > In such a case... > > > policies and prevent access to confidential traffic measurements by > > other people. Typically, anonymization techniques enables the > > provision of traffic data to other people without violating these > > policies. > > > > Generally, anonymization modifies a data set to protect the identity > > of the people or entities described by the data set from being > > disclosed. It also attempts to preserve sets of network traffic > > properties useful for a given analysis while ensuring the data cannot > > be traced back to the specific networks, hosts, or users generating > > the traffic. For example, IP address anonymization is particularly > > important for avoiding the identification of the users, hosts, and > > routers. > > > > Implementation analysis: > > > > One possible implementation for this case uses an anonymization > > function at the Original Exporter. However, this increases the > > load on the Original Exporter. A more flexible implementation > > uses a separate IPFIX Masquerading Proxy between the Original > > Exporter and Collector. > > > > 5.7. Data Retention > > > > Data retention refers to the storage of traffic data by service > > providers and commercial organizations. Network administrators > > administrators => operators ? > Yes. > > should retain both IP and voice traffic data, in wired and wireless > > "should retain" sounds like "SHOULD retain", which is definitively not > what we want to specify in an IETF standard. > > Better something like: "Legislative regulations often require that > network operators retain..." Good idea. > > What do you mean by "voice traffic data"? > As far as I known, records of VoIP connections are to be retained, but > not the voice data. > > I assume that wiretapping telephone calls must be explicitly requested > by a judge in must democratic countries. It does not fall under the > general data retention policies. Thank you for your advices. I intend the Call Detail Records including caller number, callee number, call duration and start time for the session, not wiretapping. The sentence can be modified as follows. "Legislative regulations often require that network operators retain both IP traffic data and call detail records, in wired and wireless networks, generated by end users while using a service provider's services." > > > networks, generated by end users while using a service provider's > > services. The traffic data is required for the purpose of the > > investigation, detection and prosecution of serious crime, if > > necessary. Data retention services examples are the following: > > > > o Fixed telephony (includes fixed voice calls, voicemail, and > > conference and data calls) > > > > o Mobile telephony (includes mobile voice calls, 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 > > > > Data retention for Internet access services in particular requires a > > measurement system with reliable export and huge storage as the data > > must be available for a long period of time, typically a couple of > > years. > > A couple of years sounds unrealistic. As far as I know, it's six months > in the EU. Longer retention times are usually prevented by privacy laws. I will rephrase it with "typically at least six months". Wikipedia say that a period is between 6 months and 2 years. http://en.wikipedia.org/wiki/Telecommunications_data_retention > > > Implementation analysis: > > > > Regarding export reliability requirement, the most suitable > > implementation uses the SCTP transport protocol between the > > Original Exporter and Collector. If a unreliable transport > > an unreliable > > > protocol such as UDP is used, a legacy exporting device exports > > Data Records to a nearby IPFIX Proxy through UDP, and then an > > IPFIX Proxy could reliably export them to the top IPFIX Collector > > through SCTP. If a unreliable transport protocol such as UDP is > > used and if there is no IPFIX Proxy, the legacy exporting device > > must duplicate the exports to several Collectors. > > I would remove the last sentence. Losses are provoked by congestion. > Doubling the exported data increases the risk of congestion. > Yes. > > Regarding huge storage requirement, one possible implementation > > uses a decentralized set of Collectors. If administrators need to > > retrieve specific Data Records, these Collectors would need to be > > equipped with IPFIX Mediations. > > > > 5.8. IPFIX Export from a Branch Office > > > > Generally, in large enterprise networks, Data Records from branch > > offices are gathered in a central office. However, in the long > > distance branch office case, the bandwidth for transport IPFIX is > > limited. Therefore, even if multiple Flow Records type should be of > > Data Record types? > Yes. > > interest to the Collector (Flow Records in both directions, Flow > > "(e.g., IPFIX Flow Records for both directions,...)" > > > Records before and after WAN optimization techniques, performance > > metrics associated with the Flow Records exported on regular > > interval), the export bandwidth limitation is an important factor to > > pay attention to. > > > > Implementation analysis: > > > > One possible implementation for the case uses an IPFIX > > this case > > > Concentrator located in a branch office. The IPFIX Concentrator > > would aggregate and correlate Flow Records to cope with the export > > Data Records? > Yes. > > bandwidth limitation. > > > > 5.9. Distributing Data Records > > > > Recently, several networks have shifted towards integrated networks, > > such as the pure IP and MPLS, which includes IPv4, IPv6, and VPN > > "pure IP and MPLS networks"? > Yes. > > traffic. Data Record types (IPv4, IPv6, MPLS, and VPN) need to be > > analyzed separately and from different perspectives for different > > organizations. A single Collector handling all Data Record types > > might become a bottleneck in the collecting infrastructure. Data > > Records distributed based on their respective types can be exported > > to the appropriate Collector, resulting in the load distribution > > amongst multiple Collectors. > > > > Implementation analysis: > > > > One possible implementation for this case uses the replications of > > the IPFIX Message in an Original Exporter for multiple IPFIX > > Collectors. Each Collector then extracts the Data Record required > > by its own applications. However, the replication increases the > > load of the Exporting Process and the waste of the bandwidth > > between the Exporter and Collector. > > > > A more sophisticated implementation uses an IPFIX Distributor > > located between the Metering Processes and Exporting Processes in > > an Original Exporter. The IPFIX Distributor determines > > respectively to which Collector a Data Record is exported by > > remove "respectively"? > > > filtering certain field values. If a Original Exporter does not > > "by filtering..." => "depending on certain field values" > Yes. > > have IPFIX Distributor capability, it exports Data Records to a > > nearby separate IPFIX Distributor, and then the IPFIX Distributor > > could distribute them to the appropriate IPFIX Collectors. > > > > For example, in the case of distributing a specific customer's > > Data Records, an IPFIX Distributor needs to identify the customer > > networks. The Route Distinguisher (RD), ingress interface, > > peering AS number, or BGP Next-Hop, or simply the network prefix > > may be evaluated to distinguish different customer networks. In > > the following figure, the IPFIX Distributor reroutes Data Records > > on the basis of the RD value. This system enables each customer's > > traffic to be inspected independently. > > > > .---------. > > |Traffic | > > .---->|Collector|<==>Customer#A > > | |#1 | > > | '---------' > > RD=100:1 > > .----------. .-----------. | > > |IPFIX | |IPFIX |----' .---------. > > |Exporter#1| |Distributor| RD=100:2 |Traffic | > > | |------->| |--------->|Collector|<==>Customer#B > > | | | | |#2 | > > | | | |----. '---------' > > '----------' '-----------' | > > RD=100:3 > > | .---------. > > | |Traffic | > > '---->|Collector|<==>Customer#C > > |#3 | > > '---------' > > > > Figure A: Distributing Data Records to Collectors using IPFIX > > Distributor > > > > 5.10. Flow-based Sampling and Selection > > > > 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 measurement > > system is overwhelmed with a huge amount of these small Flows. If > > statistics information of small Flows is exported as merged data by > > applying a policy or threshold, the load on the Exporter is reduced. > > Furthermore, if the flow distribution is known, exporting only a > > subset of the Data Records might be sufficient. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX > > Concentrator located between the Metering Processes and Exporting > > Processes on the Original Exporter, or alternatively as a separate > > IPFIX Concentrator located between the Original Exporters and > > IPFIX Collectors. A set of IPFIX Mediation functions, such as > > filtering, selecting and aggregation is used in the IPFIX > > Filtering, Sampling ? > Yes. > > Concentrator. > > > > 5.11. Interoperability between Legacy Protocols and IPFIX > > > > During the migration process from a legacy protocol such as NetFlow > > [RFC3954] to IPFIX, both NetFlow exporting devices and IPFIX > > Exporters are likely to coexist in the same network. Operators need > > to continue measuring the traffic data from legacy exporting devices, > > even after introducing IPFIX Collectors. > > > > Implementation analysis: > > > > One possible implementation for this case uses an IPFIX Proxy that > > converts a legacy protocol to IPFIX. > > > > 6. IPFIX Mediators Implementation Specific Problems > > > > 6.1. Loss of Original Exporter Information > > > > Both the Exporter IP address indicated by the source IP address of > > the IPFIX Transport Session and the Observation Domain ID included in > > the IPFIX Message header are likely to be lost by an IPFIX Mediator > > "lost during IPFIX Mediation."? > Yes. > > such as IPFIX Concentrator too. In some cases, a IPFIX Masquerading > > remove "such as IPFIX Concentrator" > Yes. > > Proxy might drop the information. In other cases, the Collector must > > "...might drop the information deliberately" ? > Yes. > > recognize the Original Exporter (and potentially the Observation > > Domain and Observation Point as well) whether Data Records go through > > rephrase: > "In general, however, the Collector must recognize the origin of the > measurement information, such as the IP address of the Original > Exporter, the Observation Domain ID, or even the Observation Point ID." > Yes, indeed. > > an IPFIX Mediator or not. Note that, if the Mediator can not > > communicate the Original Exporter IP address, then the top level > > Collector will wrongly deduce that the IP address of the IPFIX > > Mediator is that of the Original Exporter. > > > > In the following figure, a Collector can identify two IP addresses: > > 10.1.1.3 (IPFIX Mediator) and 10.1.1.2 (Exporter#2), respectively. > > The Collector, however, needs to somehow recognize both Exporter#1 > > and Exporter#2, which are the Original Exporters. The IPFIX Mediator > > must have a specific way to the Original Exporter IP address to the > > "must be able to notify the Collector about the IP address of the > Original Exporter." > Yes. > > IPFIX Collector. > > > > .----------. .--------. > > |IPFIX | |IPFIX | > > |Exporter#1|--------->|Mediator|---+ > > | | | | | > > '----------' '--------' | .---------. > > IP:10.1.1.1 IP:10.1.1.3 '----->|IPFIX | > > ODID:10 ODID:0 |Collector| > > +----->| | > > .----------. | '---------' > > |IPFIX | | > > |Exporter#2|-----------------------' > > | | > > '----------' > > IP:10.1.1.2 > > ODID:20 > > > > Figure B: Loss of Original Exporter Information. > > > > 6.2. Loss of Base Time Information > > > > The Export Time field included in the IPFIX Message header indicates > > the base time for Data Records. IPFIX Information Elements, > > "...indicates the base time" => "...represents a reference timestamp..." > > " _Some_ IPFIX Information Elements..." > > > described in [RFC5102], have delta time fields that indicate the time > > "have delta time fields" => "carry delta timestamps" ? > Yes. > > difference from the value of the Export Time field. If the Data > > Records include any delta time fields and the IPFIX Mediator > > overwrites the Export Time field when sending IPFIX Messages, the > > delta time fields become meaningless and, because Collectors cannot > > recognize this situation, wrong time values are propagated. > > > > 6.3. Transport Sessions Management > > > > Maintaining relationships between the incoming Transport Sessions and > > the outgoing ones depends on the Mediator's implementation. If > > Better: > "If an IPFIX Mediator relays multiple incoming Transport Sessions to a > single outgoing Transport Session, ..." > Yes. > > multiple incoming Transport Sessions are relayed to a single outgoing > > Transport Session, and if the IPFIX Mediators shuts down its outgoing > > Transport Session, Data Records on other incoming Transport Sessions > > "... Data Records of the incoming Transport Sessions would not be > relayed any more." > > > would not be relayed at all. In the case of resetting of an incoming > > remove "of" > > > session, the behavior of the IPFIX Mediator needs to be specified. > > > > 6.4. 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 > > "...reported in the Data Records defined by Option Templates..." Yes, indeed. > > > could also be lost. If, for example, the Sampling rate is not > > communicated from the Mediator to the Collector, the Collector would > > miscalculate the traffic volume. This might lead to crucial > > problems. Even if an IPFIX Mediator was to simply relay received > > Option Template Information, the values of its scope fields could > > "Option Data Records"? Yet this is not an official term either. > I can rephrase it, as follows. "... received Data Records defined by Options Templates, the values of its scope fields could..." > > become meaningless in the context of a different Transport Sessions. > > The minimal information to be communicated by an IPFIX Mediator must > > be specified. > > > > 6.5. Template ID Management > > > > The Template ID is unique on the basis of the Transport Session and > > Observation Domain ID. If Mediations are not able to manage the > > "Mediations are" => "IPFIX Mediation is" > Yes. > > relations amongst the Template IDs and the incoming Transport Session > > information, and if the Template ID is used in the Options Template > > scope, the Mediators would, for example, relay wrong values in the > > "the Mediators" => "IPFIX Mediators" > Yes. > > scope field and in the Template Withdrawal Message. The Collector > > would thus not be able to interpret the Template ID in the Template > > Withdrawal Message and in the Options Template scope. As a > > consequence, there is a risk that the Collector would then shut down > > the IPFIX Transport Session. > > > > For example, an IPFIX Distributor must maintain the state of the > > incoming Transport Sessions in order to manage the Template ID on its > > outgoing Transport Session correctly. In the following figure, even > > The rest of the paragraph is unclear: > > > if the Transport Session from Exporter re-initializes, the IPFIX > > Distributor must manage the association of Template IDs in specific > > Transport Session. Typically, when the Exporter#1 Transport Session > > re-initialized, the Template ID 256 replaced the previous Template ID > > 258, while the IPFIX Distributor will keep exporting the Template ID > > 256 to the Collector. > > Are all Templates identical? Or how comes that there is only one > Template in the outgoing Transport Session? > > Please explain better. > I image that IPFIX Distributor exports 3 templates including template ID 256, template ID 257, and template ID 258. All templates are kept the template ID value from input Transport Session. Even when the Exporter 1 is re-initialized and the template 258 is replaced with 256, IPFIX Distributor must avoid the duplication of template ID values. I will improve the phrase and the following figure. > > > > > > .----------. OLD: Template ID 258 > > |IPFIX | NEW: Template ID 256 > > |Exporter#1|----+ > > | | | > > '----------' X > > .----------. | .-----------. .----------. > > |IPFIX | '---------->| | | | > > |Exporter#2|--------------->|IPFIX |-------X------>|IPFIX | > > | |Template ID 257 |Distributor|Template ID 256| Collector| > > '----------' +---------->| | | | > > .----------. | '-----------' '----------' > > |IPFIX | | > > |Exporter#3|----' > > | | Template ID 256 > > '----------' > > > > Figure C: Relaying from Multiple Transport Sessions to Single > > Transport Session. > > > > 6.6. Consideration for Network Topology > > > > While IPFIX Mediation can be applied anywhere, caution should be > > taken as how to aggregate the counters, as there is a potential risk > > of double-counting. For example, if three Exporters export Flow > > Records related to the same Flow, the one-way delay can be > > calculated, while the summing up the number of packets and bytes does > > not make sense. Alternatively, if three Exporters export Flow > > Howerver, we could calculate packet losses on the path. See comment above. > Yes. The subtracting the number of packets might result in loss packets. > > Records entering an administrative domain, then the sum of the > > packets and bytes is a valid operation. Therefore, the possible > > function to be applied to Flow Records must take into consideration > > the measurement topology. The information such as the network > > topology, or at least the Observation Point and measurement > > direction, is required on the IPFIX Mediation. > > "on the" => "for" ? > > > 6.7. Exporting the Function Item > > > > In some case, the top IPFIX Collector needs to recognize which > > remove "top"? I know what you mean, but it does not have to be clear to > all readers. > Yes. > > specific function(s) the IPFIX Mediation has executed on the Data > > Records. The IPFIX Collector cannot distinguish between Time > > Composition, Spatial Composition, and Flow Key aggregation, if the > > IPFIX Mediator does not export the applied function. Some parameters > > related to the function also would need to be exported. For example, > > in case of Time Composition, the active time of original Flow Records > > is required to interpret the minimum/maximum counter correctly. In > > case of Spatial Composition, spatial area information on which Data > > Records is aggregated is required. > > > > 6.8. Consideration for Aggregation > > > > In case of Flow Key aggregation, Time Composition, and Spatial > > Composition, there are the following considerations: > > > > o Aggregation rule for non Flow Keys > > "non Flow Keys" => "non-key fields" > > > There are no obvious rules of non Flow Keys. For example, if an > > "non Flow Keys" => "non-key fields" > > > IPFIX Mediation receives two Flow Records with different DSCP > > values, and this DSCP field is not a Flow Key, those two Flow > > Records can be aggregated based on the Flow Keys value. However, > > there is no rules for what the DSCP value should be for the > > aggregated Data Record. Potential solutions are: the value of > > Actually, there is a rule! > Unless specified differently, the value of the first packet must be > included in the record. Hence, as long as timestamps are present and > allow to determine which one of the Flow Records includes the earliest > packet, the decision is evident! > I don't undestand your points. If receiving two Flow Records ( earlier one with DSCP=1 and later one with DSCP=2), we can choose the several implementations as follows. - DSCP=1, keeping the earliest value - DSCP=2, overwriting the latter value - DSCP=0, setting the 0 values, when finding unmatch in DSCP field. - deleting DSCP field from data structure In my opinion, the topic seem not require the rule of non-key fields. But, it needs the discussion in next phase, not in problem statement phase. Even if the conclusion of discussion is no need of the rule, I expect that some document (maybe IPFIX aggregation) describes that non-key fields might result in ambiguous value. > > single of the two DSCP, the value 0 (in this case, the value 0 is > > a valid DSCP value), or removing a DSCP field in its Data Record. > > > > o Configured Selection Fraction on aggregation > > > > There is no obvious rules of how to compute Configured Selection > > Fraction, and whether a Mediator should report Configured > > remove ", and whether....," > It is obvious, that Configured or Attained Selection Fraction is > necessary to interpret the Flow Records. > > > > Selection Fraction, when aggregation resulting from Sampling. For > > "...when aggregating IPFIX Flow Records of sampled packets." > Yes. > > example, special care must be taken in the following: aggregation > > resulting from the different Configured Selection Fraction, > > aggregation resulting from different Sampling techniques, such as > > Systematic Count-Based Sampling and Random n-out-of-N Sampling > > etc. > > > > 7. Summary and Conclusion > > > > This document described the problems that network administrators have > > been facing, the applicability of IPFIX Mediation to these problems, > > and the problems related to the implementation of IPFIX Mediators. > > To assist the operations of the Exporters and Collectors, there are > > various IPFIX Mediations from which the administrators may select. > > Examples of the applicability of IPFIX Mediation are as follows. > > > > o Regarding large-scale measurement system, IPFIX Concentrators or > > IPFIX Distributors help to achieve traffic analysis with high data > > accuracy and fine flow granularity even as IP traffic grows. As > > IPFIX Mediation capabilities, Flow selection Sampling, > > flow sampling? > Yes. > > aggregation, and composition are effective. > > > > o Regarding data retention, IPFIX Mediators enhance the export > > reliability, and the storage of the measurement system. > > > > o Regarding the distribution of Data Records, IPFIX Distributors > > help to achieve multipurpose traffic analysis for different > > organizations, or help to achieve respective traffic analysis > > based on Data Record types(IPv4, IPv6, MPLS, and VPN). > > > > o Regarding IPFIX Exporting across domains, IPFIX Masquerading > > exporting > Yes. > > Proxies help administrators to anonymize or filter Flow Records/ > > Data Records > Yes. > > Packet Reports, preventing privacy violations. > > > > o Regarding interoperability, IPFIX Proxies provide interoperability > > between legacy protocols and IPFIX, even during the migration > > period to IPFIX. > > > > As a result, the IPFIX Mediation benefits become apparent. However, > > there are still some open issues with the use of IPFIX Mediators. > > > > o Both Observation Point and IPFIX Message 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 IPFIX Mediators are required to manage Transport Sessions, > > Template IDs, and Observation Domain IDs. Otherwise, anomalous > > IPFIX messages could be created. > > > > o Data advertised by Option Templates from the Original Exporter, > > _Options_ Templates > > better: > "Options Data Records exported by the Original Exporter, such as those > reporting the Sampling rate...." > > Maybe the term "Options Data Record" should be introduced to simplify > things. BTW, we had the same problem in per-sctp-stream, and always > wrote "Data Record defined by an Options Template Record", which is not > very easy to read. > Yes, indeed. I hope the term is defined in another document, not problem statement. The problem statement does not suit. > > 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. > > > > These problems stem from the fact that no standards regarding IPFIX > > Mediation have been set. In particular, the minimum set of > > information that should be communicated between Original Exporters > > and Collectors, the management between different IPFIX Transport > > Sessions, and the internal components of IPFIX Mediators should be > > standardized. > > > > 8. Security Considerations > > > > A flow-based measurement system must prevent potential security > > threats: the disclosure of confidential traffic data, injection of > > incorrect data, and unauthorized access to traffic data. These > > security threats of the IPFIX protocol are covered by the security > > considerations section in [RFC5101] and are still valid for IPFIX > > Mediators. > > > > And a measurement system must also prevent following security threats > > "...the following..." > > > related to IPFIX Mediation: > > > > o Attacks against IPFIX Mediator > > > > IPFIX Mediators can be considered as a prime target for attacks, > > as an alternative to IPFIX Exporters and Collectors. IPFIX > > Proxies or Masquerading Proxies need to prevent unauthorized > > access or denial-of-service (DoS) attacks from untrusted public > > networks. > > > > o Man-in-the-middle attack by untrusted IPFIX Mediator > > > > The Collector-Mediator-Exporter structure model would increase the > > risk of the man-in-the-middle attack. > > > > o Configuration on IPFIX Mediation > > > > In the case of IPFIX Distributors and IPFIX Masquerading Proxies, > > an accidental misconfiguration and unauthorized access to > > configuration data could lead to the crucial problem of disclosure > > of confidential traffic data. > > > -- > 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 NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Wed Jun 10 05:56:46 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780513A65A6 for ; Wed, 10 Jun 2009 05:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 I8IzZ8CTK1jm for ; Wed, 10 Jun 2009 05:56:45 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id D73D63A6A0A for ; Wed, 10 Jun 2009 05:56:44 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:cc40:6328:3285:458]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5ACumMO072515; Wed, 10 Jun 2009 21:56:49 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 10 Jun 2009 21:53:53 +0900 From: Atsushi Kobayashi To: Juergen Schoenwaelder In-Reply-To: <20090520220140.GA6311@elstar.local> References: <20090520220140.GA6311@elstar.local> Message-Id: <20090610214015.6E56.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Wed, 10 Jun 2009 21:56:50 +0900 (JST) Cc: IETF IPFIX Working Group , Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:56:46 -0000 Dear Juergen, Sorry for late reply. > * 6.8: > > I am not how to read 'when aggregation resulting from Sampling' in > this sentence: > > There is no obvious rules of how to compute Configured Selection > Fraction, and whether a Mediator should report Configured > Selection Fraction, when aggregation resulting from Sampling. > I indicate that there is no obvious rules in case of aggregation for Flow Records resulting from packet sampling. In case of aggregation for Flow Records from different Exporters with same sampling interval, or with different sampling interval, we need to discuss need of Configured Selection Fraction, and discuss how to compute it in next phase. I will improve the sentences. Regards, Atsushi KOBAYASHI > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From Sven.Anderson@CS.Uni-Goettingen.DE Wed Jun 10 07:06:15 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2701B3A6A91 for ; Wed, 10 Jun 2009 07:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luXiBq8ULMVp for ; Wed, 10 Jun 2009 07:06:13 -0700 (PDT) Received: from serv-80-156.SerNet.DE (serv-80-156.SerNet.de [193.175.80.156]) by core3.amsl.com (Postfix) with ESMTP id 9B35C3A6841 for ; Wed, 10 Jun 2009 07:06:12 -0700 (PDT) Received: from dslb-088-070-019-112.pools.arcor-ip.net ([88.70.19.112] helo=[192.168.0.52]) by serv-80-156.SerNet.DE with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.51) id 1MEORU-0006Z1-Uq; Wed, 10 Jun 2009 16:06:17 +0200 Message-Id: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> From: Sven Anderson To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 16:06:15 +0200 References: <20090610095021.GA5866@elstar.local> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 14:06:15 -0000 Am 10.06.2009 um 12:49 schrieb Romascanu, Dan (Dan): > You are correct about media recording. A session is however composed > out > of media and signaling (sometimes going on different paths). For the > signaling part IPFIX may be sufficient. I just presented SIPFIX at the IM 2009 conference, which is an IPFIX based SIP monitoring scheme [1]. We will soon submit an Internet-Draft as well. They might be interested in it. [1] http://sven.anderson.de/publications/sipfix.pdf Sven > >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Wednesday, June 10, 2009 12:50 PM >> To: Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group >> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP >> >> On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote: >> >>> I threw a comment in this discussion that IPFIX may be a >> technology to >>> be considered for session recording. >>> >>> Any opinions or suggestions on this idea? >> >> They want to record complete media streams. IPFIX supports >> the export of flow summary records. I do not see a relation here. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > From akoba@nttv6.net Wed Jun 10 08:46:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC323A6C67 for ; Wed, 10 Jun 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 2C-pPSdgS0Cm for ; Wed, 10 Jun 2009 08:46:26 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id F1F9D3A6C5A for ; Wed, 10 Jun 2009 08:46:25 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:cc40:6328:3285:458]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5AFkFXf073357; Thu, 11 Jun 2009 00:46:16 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 11 Jun 2009 00:43:19 +0900 From: Atsushi Kobayashi To: Sven Anderson In-Reply-To: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> References: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> Message-Id: <20090611002755.6E5C.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 11 Jun 2009 00:46:16 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 15:46:27 -0000 Dear Sven, and Dan, SIPFIX is interesting approach. Complete call records including the caller URI, callee URI, RTP media quality, and etc. are created after correlating SIP summary records and RTP summary records in mediation. As another approach, I presented the following in last IEPG meeting. http://www.nttv6.net/~akoba/iepg_ipfix.pdf The approach continuously measures the SIP signaling, and then extracts the media information from SDP on SIP packet. If necessary, IPFIX-CONFIG including the filtering rule for RTP packets can be configured on Exporter, and then it measures the RTP media stream on demand. Both approaches illustrate that IPFIX can contribute to monitor the SIP signaling and RTP media stream. I hope that the topic can be discussed in next IPFIX meeting. Regards, Atsushi KOBAYASHI On Wed, 10 Jun 2009 16:06:15 +0200 Sven Anderson wrote: > > Am 10.06.2009 um 12:49 schrieb Romascanu, Dan (Dan): > > > You are correct about media recording. A session is however composed > > out > > of media and signaling (sometimes going on different paths). For the > > signaling part IPFIX may be sufficient. > > I just presented SIPFIX at the IM 2009 conference, which is an IPFIX > based SIP monitoring scheme [1]. We will soon submit an Internet-Draft > as well. They might be interested in it. > > [1] http://sven.anderson.de/publications/sipfix.pdf > > Sven > > > > > >> -----Original Message----- > >> From: Juergen Schoenwaelder > >> [mailto:j.schoenwaelder@jacobs-university.de] > >> Sent: Wednesday, June 10, 2009 12:50 PM > >> To: Romascanu, Dan (Dan) > >> Cc: IETF IPFIX Working Group > >> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP > >> > >> On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote: > >> > >>> I threw a comment in this discussion that IPFIX may be a > >> technology to > >>> be considered for session recording. > >>> > >>> Any opinions or suggestions on this idea? > >> > >> They want to record complete media streams. IPFIX supports > >> the export of flow summary records. I do not see a relation here. > >> > >> /js > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >> Fax: +49 421 200 3103 > >> > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dromasca@avaya.com Wed Jun 10 08:56:08 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51C253A6B0B for ; Wed, 10 Jun 2009 08:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 iZ1rpi7jYEUM for ; Wed, 10 Jun 2009 08:56:07 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 1E9643A6831 for ; Wed, 10 Jun 2009 08:56:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,342,1241409600"; d="scan'208";a="163904349" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 Jun 2009 11:56:12 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2009 11:56:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jun 2009 17:55:50 +0200 Message-ID: In-Reply-To: <20090611002755.6E5C.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re[2]: [IPFIX] FW: [dispatch] Session recording in SIP Thread-Index: Acnp4p2fcqEeHfOwRK6RBQQ4WMHAqwAAPkYQ References: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> <20090611002755.6E5C.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" , "Sven Anderson" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 15:56:08 -0000 I am looking forward to your proposal, but SIP session recording (which is where the discussion started from) has different requirements than SIP monitoring. =20 Dan > -----Original Message----- > From: Atsushi Kobayashi [mailto:akoba@nttv6.net]=20 > Sent: Wednesday, June 10, 2009 6:43 PM > To: Sven Anderson > Cc: Romascanu, Dan (Dan); IETF IPFIX Working Group > Subject: Re[2]: [IPFIX] FW: [dispatch] Session recording in SIP >=20 >=20 > Dear Sven, and Dan, >=20 > SIPFIX is interesting approach. Complete call records=20 > including the caller URI, callee URI, RTP media quality, and=20 > etc. are created after correlating SIP summary records and=20 > RTP summary records in mediation. >=20 > As another approach, I presented the following in last IEPG meeting.=20 > http://www.nttv6.net/~akoba/iepg_ipfix.pdf >=20 > The approach continuously measures the SIP signaling, and=20 > then extracts the media information from SDP on SIP packet.=20 > If necessary, IPFIX-CONFIG including the filtering rule for=20 > RTP packets can be configured on Exporter, and then it=20 > measures the RTP media stream on demand. >=20 > Both approaches illustrate that IPFIX can contribute to=20 > monitor the SIP signaling and RTP media stream. I hope that=20 > the topic can be discussed in next IPFIX meeting. >=20 > Regards, > Atsushi KOBAYASHI >=20 > On Wed, 10 Jun 2009 16:06:15 +0200 > Sven Anderson wrote: >=20 > >=20 > > Am 10.06.2009 um 12:49 schrieb Romascanu, Dan (Dan): > >=20 > > > You are correct about media recording. A session is=20 > however composed=20 > > > out of media and signaling (sometimes going on different=20 > paths). For=20 > > > the signaling part IPFIX may be sufficient. > >=20 > > I just presented SIPFIX at the IM 2009 conference, which is=20 > an IPFIX=20 > > based SIP monitoring scheme [1]. We will soon submit an=20 > Internet-Draft=20 > > as well. They might be interested in it. > >=20 > > [1] http://sven.anderson.de/publications/sipfix.pdf > >=20 > > Sven > >=20 > >=20 > > > > > >> -----Original Message----- > > >> From: Juergen Schoenwaelder > > >> [mailto:j.schoenwaelder@jacobs-university.de] > > >> Sent: Wednesday, June 10, 2009 12:50 PM > > >> To: Romascanu, Dan (Dan) > > >> Cc: IETF IPFIX Working Group > > >> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP > > >> > > >> On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan=20 > (Dan) wrote: > > >> > > >>> I threw a comment in this discussion that IPFIX may be a > > >> technology to > > >>> be considered for session recording. > > >>> > > >>> Any opinions or suggestions on this idea? > > >> > > >> They want to record complete media streams. IPFIX supports the=20 > > >> export of flow summary records. I do not see a relation here. > > >> > > >> /js > > >> > > >> --=20 > > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1, 28759=20 > Bremen, Germany > > >> Fax: +49 421 200 3103 =20 > > > >> > > > _______________________________________________ > > > IPFIX mailing list > > > IPFIX@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipfix > > > > >=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=20 > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=20 >=20 From muenz@net.in.tum.de Sun Jun 14 03:32:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94543A69A7 for ; Sun, 14 Jun 2009 03:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuvVh5EijgBz for ; Sun, 14 Jun 2009 03:32:15 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 19B973A67DB for ; Sun, 14 Jun 2009 03:32:14 -0700 (PDT) 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 C8F1347BF2; Sun, 14 Jun 2009 12:32:21 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id EDC952EED; Sun, 14 Jun 2009 12:32:20 +0200 (CEST) Message-ID: <4A34D206.4070704@net.in.tum.de> Date: Sun, 14 Jun 2009 12:33:42 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> In-Reply-To: <20090610211008.6E53.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040504070008030203020108" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 10:32:17 -0000 This is a cryptographically signed message in MIME format. --------------ms040504070008030203020108 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Atsushi, all, Actually, I was surprised and a little bit disappointed that J=FCrgen and= me were the only ones who answered to the WGLC - or did I miss something?= Even though this is "only" an informational problem statement, I think it would be useful to have more reviewers and more discussion. Otherwise, it looks like a lack of interest in IPFIX mediation - and no interest means that there is no need for a standard. Please find comments inline: >> In my opinion, the terminology related to Mediation must be rethought >> another time before publishing this problem statement as an RFC. >> The current terminology section defines the following terms: >> >> *IPFIX Mediation* >> =3D a function >> >> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >> =3D specific types of IPFIX Mediation >> > Do you suggest that they are a specific type of device? >=20 > e.g. >=20 > IPFIX Proxy >=20 > An IPFIX Proxy is a type of IPFIX Mediator that relays incoming > ^^^^^^^^=20 > Transport Sessions to one or multiple Collectors.=20 >=20 > Your points are reasonable for me, the further discussion with co-autho= rs > is needed to address it. >=20 >> *IPFIX Mediator* >> =3D devices that implements IPFIX Mediation >> >=20 > If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are > defined as the devices, I think that the following issues can be solved= =2E Yes, I think that IPFIX Concentrator, Proxy, etc. should be defined as devices. IPFIX Mediator can be an umbrella term for all of them. This change will result in a couple of further changes in the text. E.g. in the introduction: While the IPFIX requirements defined in [RFC3917] mention an _intermediate function_, such as an IPFIX Proxy or an IPFIX Concentrator, there are no documents defining the function called IPFIX Mediation. "intermediate function" needs to be replaced, e.g. by "device"? >> This terminology has several flaws: >> - On the one hand, you have troubles to distinguish between IPFIX >> Mediation implemented at an "Original Exporter" and IPFIX Mediation >> implemented at a "separate IPFIX Mediator/Concentrator/...". >> - On the other hand, the terms do not fit into the current terminology= >> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >> talk about the instantiation of a specific function. >=20 > I will add "XXX Process" terms in framework draft rather than problem > statement. It seems better that the problem statement draft does not > include the "XXX Process" terms illustrating the implementation. > >> - Finally, the definition of IPFIX Concentrator does not correspond to= >> the usage of this term in RFC3917. There, a Concentrator is a device, >> not a function. >> >> I like the approach that has been chosen by PSAMP. There, we distingui= sh >> between "Selectors" (which are abstract selection functions) and >> "Selection Processes" (which are instantiations of Selectors). Selecti= on >> Processes are finally part of Devices (i.e., PSAMP Exporters). I sugge= st >> to apply this approach to Mediation as well. >> >> In the case of Mediation, we would have abstract Mediation Functions >> (anonymization, aggregation, sampling, proxy, distribution). These wou= ld >> be instantiated in a Mediation Process. A Mediation Process can then b= e >> part of an Exporter (Original Exporter), Collector, or Mediator. >=20 > Yes. We can describe the your suggestion as "Intermediate Process" in > framework draft.=20 Ok. >>> The recent continued IP traffic growth has been overwhelming the >> "The sustained growth of IP traffic..." ? >> >>> measurement system capacity, and multi-purposing applications, alo= ng >> multi-purpose? >> >> Yet, it is not clear to me what you mean. >> >=20 > I means that implementation of multiple traffic measurements, such as > QoS measurement and traffic engineering, have been contributing to a > complex situation, and executing it with the heterogeneous environments= > also results in further more complex. >=20 >>> with the heterogeneous environments, have further been contributin= g >>> to a complex situation. =20 Ok, so maybe two sentences: "The sustained growth of IP traffic has been overwhelming measurement system capacities. Furthermore, a large variety of applications (e.g., QoS measurement, traffic engineering, security monitoring) and the deployment of IP traffic measurements in heterogeneous environments have been increasing the demand and complexity of IP traffic measurements." >>> The following sub-sections explain different >>> problems in more details. >>> >>> 4.1. Coping with IP Traffic Growth >>> >>> Enterprise or service provider networks already have multiple 10 G= b/s >>> links, their total traffic exceeding 100 Gb/s. In the near future= , >>> broadband users' traffic will increase by approximately 40% every >>> year according to [TRAFGRW]. When operators monitor traffic of 50= 0 >>> 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. >>> >>> To deal with this problem, current data reduction techniques, such= as >>> Sampling, Filtering, Data Records aggregation have been generally >> For me, "aggregation" refers to the semantic level of exported >> information. Therefore, I would call it "flow aggregation" instead of >> "Data Record aggregation". >=20 > Does the flow in "flow aggregation" indicate general 7-tuple flow in > NetFlow? It needs the distinction between flow in NetFlow and Flow in > IPFIX, since the Flow term in IPFIX covers an aggregated Flow. Well, to what kind of aggregation do you want to refer in this sentence? What kind of aggregation is currently implemented apart from flow aggregation in the sense of aggregating 7-tuple flows? To be more general, you could write: "To deal with this problem, current data reduction techniques, such as Sampling, Filtering, aggregation of measurement data,..." >>> implemented on Exporters. Note that Sampling technique leads to >>> etc.), and data format. For example, probes and switches cannot >>> retrieve packet property information from a route table. >> Do you mean AS information? >> > Yes.=20 >=20 > "For example, probes and switches cannot retrieve some Derived Packet > Properties in [RFC5102] from a route table." "..., such as the autonomous systems of source and destination IP addresses." ? >>> * Treatment from the correlation of Data Records with the same= >> IPFIX Flow Records? >> >=20 > In that case, both of IPFIX Flow Records and PSAMP Packet Reports can b= e > applied. Hm, Packet Reports do not have "Flow Key(s)" as mentioned in the sentence, do they? >>> Flow Key(s) observed at incoming/outgoing interfaces. Examp= les >>> are the rate-limiting ratio, the compression ratio, the >>> optimization ratio, etc. >>> 5.4. Time Composition >>> >>> Time composition is defined as the aggregation of consecutive Data= >> in this case: IPFIX Flow Records >> >=20 > Aggregation (including the Time composition) can be applied to both of > input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this > case keeps "Data Records". Same as above: PSAMP Packet Reports does not have Flow Key(s). So, the sentence only works for Flow Records. >>> Records with identical Flow Keys. It leads to the same output as >>> For example, an IPFIX Distributor must maintain the state of the >>> incoming Transport Sessions in order to manage the Template ID on = its >>> outgoing Transport Session correctly. In the following figure, ev= en >> The rest of the paragraph is unclear: >> >>> if the Transport Session from Exporter re-initializes, the IPFIX >>> Distributor must manage the association of Template IDs in specifi= c >>> Transport Session. Typically, when the Exporter#1 Transport Sessi= on >>> re-initialized, the Template ID 256 replaced the previous Template= ID >>> 258, while the IPFIX Distributor will keep exporting the Template = ID >>> 256 to the Collector. >> Are all Templates identical? Or how comes that there is only one >> Template in the outgoing Transport Session? >> >> Please explain better. >> >=20 > I image that IPFIX Distributor exports 3 templates including > template ID 256, template ID 257, and template ID 258. All templates ar= e > kept the template ID value from input Transport Session. Even when the > Exporter 1 is re-initialized and the template 258 is replaced with 256,= IPFIX > Distributor must avoid the duplication of template ID values. The mapping of incoming Template IDs to outgoing Template IDs is not clear from the figure. Maybe a table would help to explain. And again: Exporter 1's Templates 256 and 258 are identical, right? > I will improve the phrase and the following figure. >=20 >>> >>> .----------. OLD: Template ID 258 >>> |IPFIX | NEW: Template ID 256 >>> |Exporter#1|----+ >>> | | | >>> '----------' X >>> .----------. | .-----------. .---------= -. >>> |IPFIX | '---------->| | | = | >>> |Exporter#2|--------------->|IPFIX |-------X------>|IPFIX = | >>> | |Template ID 257 |Distributor|Template ID 256| Collecto= r| >>> '----------' +---------->| | | = | >>> .----------. | '-----------' '---------= -' >>> |IPFIX | | >>> |Exporter#3|----' >>> | | Template ID 256 >>> '----------' >>> >>> Figure C: Relaying from Multiple Transport Sessions to Single >>> Transport Session. >>> 6.8. Consideration for Aggregation >>> >>> In case of Flow Key aggregation, Time Composition, and Spatial >>> Composition, there are the following considerations: >>> >>> o Aggregation rule for non Flow Keys >> "non Flow Keys" =3D> "non-key fields" >> >>> There are no obvious rules of non Flow Keys. For example, if a= n >> "non Flow Keys" =3D> "non-key fields" >> >>> IPFIX Mediation receives two Flow Records with different DSCP >>> values, and this DSCP field is not a Flow Key, those two Flow >>> Records can be aggregated based on the Flow Keys value. Howeve= r, >>> there is no rules for what the DSCP value should be for the >>> aggregated Data Record. Potential solutions are: the value of >> Actually, there is a rule! >> Unless specified differently, the value of the first packet must be >> included in the record. Hence, as long as timestamps are present and >> allow to determine which one of the Flow Records includes the earliest= >> packet, the decision is evident! >> >=20 > I don't undestand your points. >=20 > If receiving two Flow Records ( earlier one with DSCP=3D1 and later one= > with DSCP=3D2), we can choose the several implementations as follows. > - DSCP=3D1, keeping the earliest value This is the correct solution! Because RFC5102 says: "For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines that their value is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics." > - DSCP=3D2, overwriting the latter value > - DSCP=3D0, setting the 0 values, when finding unmatch in DSCP field. These two options lead to invalid field value according to RFC5102. > - deleting DSCP field from data structure This is also possible. > In my opinion, the topic seem not require the rule of non-key fields. > But, it needs the discussion in next phase, not in problem statement > phase. Even if the conclusion of discussion is no need of the rule, I > expect that some document (maybe IPFIX aggregation) describes that > non-key fields might result in ambiguous value. There is no need for a new rule because RFC 5102 already specifies what needs to be done! >>> single of the two DSCP, the value 0 (in this case, the value 0 = is >>> a valid DSCP value), or removing a DSCP field in its Data Recor= d. 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 --------------ms040504070008030203020108 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE0MTAzMzQyWjAjBgkqhkiG9w0BCQQxFgQU EQSzXwtlFc1N3eEwkhTFbHQ/DrQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAIlOmin7wfoO5N733YD+g/uEdhNa694cuT606VfgLVJUmGuO UAFTAE+q/HIQWsDMPsdAxVBpMut7UX29Y79xvCyfzsrKaTH8IheDlamQpxCQxOYXL61XGECQ 55bx9ESB5A2zzp9VGLy+eyIaZo/HU4CXh8iC2htGSh8Iec+X3lAeNlQa7vs+c5rjPJ64OoW/ 8hgAhIMEgPOs86iRu6lfLlC4w7mJz0Na2oez4khK1OejYf2Cn3cTF6GOdSe/qMg9ZhwQaB3Z 4M+caoKNptYoJTd1j/rKU0Osj5FHLjytY3jc8Wk0rPv5ZhzNjV3vwilD7FHEEm72/O7eWskI xF/CzA0AAAAAAAA= --------------ms040504070008030203020108-- From muenz@net.in.tum.de Sun Jun 14 13:54:55 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B433A689C for ; Sun, 14 Jun 2009 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, HELO_EQ_DE=0.35, URIBL_RHS_DOB=1.083] 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 yOJjW+HG870s for ; Sun, 14 Jun 2009 13:54:54 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id D56F63A65A6 for ; Sun, 14 Jun 2009 13:54:52 -0700 (PDT) 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 BF29E47BF2; Sun, 14 Jun 2009 22:54:49 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id DA0372234; Sun, 14 Jun 2009 22:54:48 +0200 (CEST) Message-ID: <4A3563EA.4010906@net.in.tum.de> Date: Sun, 14 Jun 2009 22:56:10 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Sven Anderson References: <20090610095021.GA5866@elstar.local> <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> In-Reply-To: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070709030006080600060107" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 20:54:55 -0000 This is a cryptographically signed message in MIME format. --------------ms070709030006080600060107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sven, all, I had a look at your paper. Indeed, it's an interesting use-case for IPFIX which shows that the IPFIX protocol is flexible enough to transport many different kinds of information. However, I do not see any standardization issue here, apart from a couple of new Information Elements. Also, the concept of Mediators is not as essential for your purpose as you claim. The correlation of different records can also be done at the Collector. What about encryption? With IPSec, TLS, or DTLS, you won't be able to extract any of the SIP fields with passive monitoring. This is a strong limitation of the approach. Regards, Gerhard Sven Anderson wrote: >=20 > Am 10.06.2009 um 12:49 schrieb Romascanu, Dan (Dan): >=20 >> You are correct about media recording. A session is however composed o= ut >> of media and signaling (sometimes going on different paths). For the >> signaling part IPFIX may be sufficient. >=20 > I just presented SIPFIX at the IM 2009 conference, which is an IPFIX > based SIP monitoring scheme [1]. We will soon submit an Internet-Draft > as well. They might be interested in it. >=20 > [1] http://sven.anderson.de/publications/sipfix.pdf >=20 > Sven >=20 >=20 >> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Wednesday, June 10, 2009 12:50 PM >>> To: Romascanu, Dan (Dan) >>> Cc: IETF IPFIX Working Group >>> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP >>> >>> On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote:= >>> >>>> I threw a comment in this discussion that IPFIX may be a >>> technology to >>>> be considered for session recording. >>>> >>>> Any opinions or suggestions on this idea? >>> >>> They want to record complete media streams. IPFIX supports >>> the export of flow summary records. I do not see a relation here. >>> >>> /js >>> >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix >> >=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 --------------ms070709030006080600060107 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE0MjA1NjEwWjAjBgkqhkiG9w0BCQQxFgQU 8PKsRzj+SQ7zOZzHv+0EXSnt3xIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALhyPS+yF2fB5WXxuWvQUCEka6hn4GtSiwPXQmaWRdUp6YwG C4LLleBWLpIV4OmGywKr729HSkuDuxGGhpwRtIi+hvMGyEmt7VLgztIP2bNDruCv6ztob7hf QpBwo/5PgreHoTFAzh98L9AbaUxEmhCksJaPVdZpi8bqSHjMqOSPu5gkMrQYFKpZVsc1WpsW Vmlij0xyR9HYXbO7mjZARzTsXYYSnzSzOSU3Xz5+HFQ1fdIw1L1GQHLPtyiQZN98VMmhzQNp Tkc7Ow11XURk47kSUsN2+ziFiLhmBSckSFUxUk5T0Bq/OP5FZI65MYw+coMB/9eNBsW/lJvY TvmA/t8AAAAAAAA= --------------ms070709030006080600060107-- From akoba@nttv6.net Mon Jun 15 03:05:53 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB15D28C113 for ; Mon, 15 Jun 2009 03:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.134 X-Spam-Level: X-Spam-Status: No, score=-0.134 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 KH9N2S5aK5TR for ; Mon, 15 Jun 2009 03:05:52 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 33D5C28C0D7 for ; Mon, 15 Jun 2009 03:05:50 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:3416:4e85:1504:25a5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5FA5vSJ043586; Mon, 15 Jun 2009 19:05:58 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 15 Jun 2009 19:02:47 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A34D206.4070704@net.in.tum.de> References: <20090610211008.6E53.17391CF2@nttv6.net> <4A34D206.4070704@net.in.tum.de> Message-Id: <20090615163232.B555.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 15 Jun 2009 19:05:58 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:05:54 -0000 Dear Gerhard, and all, >=20 > Dear Atsushi, all, >=20 > Actually, I was surprised and a little bit disappointed that J=FCrgen and > me were the only ones who answered to the WGLC - or did I miss something? I have received comments from the Juergen and you. It is too few. :-( I expect the other members did not send a message yet in list. >=20 > Even though this is "only" an informational problem statement, I think > it would be useful to have more reviewers and more discussion. > Otherwise, it looks like a lack of interest in IPFIX mediation - and no > interest means that there is no need for a standard. Gerhard, thank you. Anyone's comments are welcome. Let me know your comments and feedback.=20 Please find comments inline: > >> In my opinion, the terminology related to Mediation must be rethought > >> another time before publishing this problem statement as an RFC. > >> The current terminology section defines the following terms: > >> > >> *IPFIX Mediation* > >> =3D a function > >> > >> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* > >> =3D specific types of IPFIX Mediation > >> > > Do you suggest that they are a specific type of device? > >=20 > > e.g. > >=20 > > IPFIX Proxy > >=20 > > An IPFIX Proxy is a type of IPFIX Mediator that relays incoming > > ^^^^^^^^=20 > > Transport Sessions to one or multiple Collectors.=20 > >=20 > > Your points are reasonable for me, the further discussion with co-autho= rs > > is needed to address it. > >=20 > >> *IPFIX Mediator* > >> =3D devices that implements IPFIX Mediation > >> > >=20 > > If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are > > defined as the devices, I think that the following issues can be solved. >=20 > Yes, I think that IPFIX Concentrator, Proxy, etc. should be defined as > devices. IPFIX Mediator can be an umbrella term for all of them. >=20 > This change will result in a couple of further changes in the text. > E.g. in the introduction: > While the IPFIX requirements defined in [RFC3917] mention an > _intermediate function_, such as an IPFIX Proxy or an IPFIX > Concentrator, there are no documents defining the function called > IPFIX Mediation. > "intermediate function" needs to be replaced, e.g. by "device"? Oh, yes. >=20 > >> This terminology has several flaws: > >> - On the one hand, you have troubles to distinguish between IPFIX > >> Mediation implemented at an "Original Exporter" and IPFIX Mediation > >> implemented at a "separate IPFIX Mediator/Concentrator/...". > >> - On the other hand, the terms do not fit into the current terminology > >> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we > >> talk about the instantiation of a specific function. > >=20 > > I will add "XXX Process" terms in framework draft rather than problem > > statement. It seems better that the problem statement draft does not > > include the "XXX Process" terms illustrating the implementation. > > > >> - Finally, the definition of IPFIX Concentrator does not correspond to > >> the usage of this term in RFC3917. There, a Concentrator is a device, > >> not a function. > >> > >> I like the approach that has been chosen by PSAMP. There, we distingui= sh > >> between "Selectors" (which are abstract selection functions) and > >> "Selection Processes" (which are instantiations of Selectors). Selecti= on > >> Processes are finally part of Devices (i.e., PSAMP Exporters). I sugge= st > >> to apply this approach to Mediation as well. > >> > >> In the case of Mediation, we would have abstract Mediation Functions > >> (anonymization, aggregation, sampling, proxy, distribution). These wou= ld > >> be instantiated in a Mediation Process. A Mediation Process can then b= e > >> part of an Exporter (Original Exporter), Collector, or Mediator. > >=20 > > Yes. We can describe the your suggestion as "Intermediate Process" in > > framework draft.=20 >=20 > Ok. >=20 > >>> The recent continued IP traffic growth has been overwhelming the > >> "The sustained growth of IP traffic..." ? > >> > >>> measurement system capacity, and multi-purposing applications, alo= ng > >> multi-purpose? > >> > >> Yet, it is not clear to me what you mean. > >> > >=20 > > I means that implementation of multiple traffic measurements, such as > > QoS measurement and traffic engineering, have been contributing to a > > complex situation, and executing it with the heterogeneous environments > > also results in further more complex. > >=20 > >>> with the heterogeneous environments, have further been contributin= g > >>> to a complex situation. =20 >=20 > Ok, so maybe two sentences: > "The sustained growth of IP traffic has been overwhelming measurement > system capacities. Furthermore, a large variety of applications (e.g., > QoS measurement, traffic engineering, security monitoring) and the > deployment of IP traffic measurements in heterogeneous environments have > been increasing the demand and complexity of IP traffic measurements." >=20 Yes. fine. > >>> The following sub-sections explain different > >>> problems in more details. > >>> > >>> 4.1. Coping with IP Traffic Growth > >>> > >>> Enterprise or service provider networks already have multiple 10 G= b/s > >>> links, their total traffic exceeding 100 Gb/s. In the near future= , > >>> broadband users' traffic will increase by approximately 40% every > >>> year according to [TRAFGRW]. When operators monitor traffic of 50= 0 > >>> 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. > >>> > >>> To deal with this problem, current data reduction techniques, such= as > >>> Sampling, Filtering, Data Records aggregation have been generally > >> For me, "aggregation" refers to the semantic level of exported > >> information. Therefore, I would call it "flow aggregation" instead of > >> "Data Record aggregation". > >=20 > > Does the flow in "flow aggregation" indicate general 7-tuple flow in > > NetFlow? It needs the distinction between flow in NetFlow and Flow in > > IPFIX, since the Flow term in IPFIX covers an aggregated Flow. >=20 > Well, to what kind of aggregation do you want to refer in this sentence? > What kind of aggregation is currently implemented apart from flow > aggregation in the sense of aggregating 7-tuple flows? >=20 Currently, we can use implemented NetFlow version 8 or flexible aggregation based on NetFlow version 9. As you mention, I should describe it more generally. > To be more general, you could write: > "To deal with this problem, current data reduction techniques, such as > Sampling, Filtering, aggregation of measurement data,..." >=20 > >>> implemented on Exporters. Note that Sampling technique leads to > >>> etc.), and data format. For example, probes and switches cannot > >>> retrieve packet property information from a route table. > >> Do you mean AS information? > >> > > Yes.=20 > >=20 > > "For example, probes and switches cannot retrieve some Derived Packet > > Properties in [RFC5102] from a route table." >=20 > "..., such as the autonomous systems of source and destination IP > addresses." ? >=20 > >>> * Treatment from the correlation of Data Records with the same > >> IPFIX Flow Records? > >> > >=20 > > In that case, both of IPFIX Flow Records and PSAMP Packet Reports can b= e > > applied. >=20 > Hm, Packet Reports do not have "Flow Key(s)" as mentioned in the > sentence, do they? >=20 > >>> Flow Key(s) observed at incoming/outgoing interfaces. Examp= les > >>> are the rate-limiting ratio, the compression ratio, the > >>> optimization ratio, etc. >=20 > >>> 5.4. Time Composition > >>> > >>> Time composition is defined as the aggregation of consecutive Data > >> in this case: IPFIX Flow Records > >> > >=20 > > Aggregation (including the Time composition) can be applied to both of > > input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this > > case keeps "Data Records". >=20 > Same as above: PSAMP Packet Reports does not have Flow Key(s). > So, the sentence only works for Flow Records. OK. I can use "defined common properties" instead of "Flow Key(s)" to apply to the Flow and Packet Report. > >>> Records with identical Flow Keys. It leads to the same output as >=20 > >>> For example, an IPFIX Distributor must maintain the state of the > >>> incoming Transport Sessions in order to manage the Template ID on = its > >>> outgoing Transport Session correctly. In the following figure, ev= en > >> The rest of the paragraph is unclear: > >> > >>> if the Transport Session from Exporter re-initializes, the IPFIX > >>> Distributor must manage the association of Template IDs in specifi= c > >>> Transport Session. Typically, when the Exporter#1 Transport Sessi= on > >>> re-initialized, the Template ID 256 replaced the previous Template= ID > >>> 258, while the IPFIX Distributor will keep exporting the Template = ID > >>> 256 to the Collector. > >> Are all Templates identical? Or how comes that there is only one > >> Template in the outgoing Transport Session? > >> > >> Please explain better. > >> > >=20 > > I image that IPFIX Distributor exports 3 templates including > > template ID 256, template ID 257, and template ID 258. All templates ar= e > > kept the template ID value from input Transport Session. Even when the > > Exporter 1 is re-initialized and the template 258 is replaced with 256,= IPFIX > > Distributor must avoid the duplication of template ID values. >=20 > The mapping of incoming Template IDs to outgoing Template IDs is not > clear from the figure. Maybe a table would help to explain. > And again: Exporter 1's Templates 256 and 258 are identical, right? >=20 Yes. > > I will improve the phrase and the following figure. > >=20 > >>> > >>> .----------. OLD: Template ID 258 > >>> |IPFIX | NEW: Template ID 256 > >>> |Exporter#1|----+ > >>> | | | > >>> '----------' X > >>> .----------. | .-----------. .---------= -. > >>> |IPFIX | '---------->| | | = | > >>> |Exporter#2|--------------->|IPFIX |-------X------>|IPFIX = | > >>> | |Template ID 257 |Distributor|Template ID 256| Collecto= r| > >>> '----------' +---------->| | | = | > >>> .----------. | '-----------' '---------= -' > >>> |IPFIX | | > >>> |Exporter#3|----' > >>> | | Template ID 256 > >>> '----------' > >>> > >>> Figure C: Relaying from Multiple Transport Sessions to Single > >>> Transport Session. >=20 > >>> 6.8. Consideration for Aggregation > >>> > >>> In case of Flow Key aggregation, Time Composition, and Spatial > >>> Composition, there are the following considerations: > >>> > >>> o Aggregation rule for non Flow Keys > >> "non Flow Keys" =3D> "non-key fields" > >> > >>> There are no obvious rules of non Flow Keys. For example, if a= n > >> "non Flow Keys" =3D> "non-key fields" > >> > >>> IPFIX Mediation receives two Flow Records with different DSCP > >>> values, and this DSCP field is not a Flow Key, those two Flow > >>> Records can be aggregated based on the Flow Keys value. Howeve= r, > >>> there is no rules for what the DSCP value should be for the > >>> aggregated Data Record. Potential solutions are: the value of > >> Actually, there is a rule! > >> Unless specified differently, the value of the first packet must be > >> included in the record. Hence, as long as timestamps are present and > >> allow to determine which one of the Flow Records includes the earliest > >> packet, the decision is evident! > >> > >=20 > > I don't undestand your points. > >=20 > > If receiving two Flow Records ( earlier one with DSCP=3D1 and later one > > with DSCP=3D2), we can choose the several implementations as follows. > > - DSCP=3D1, keeping the earliest value >=20 > This is the correct solution! >=20 > Because RFC5102 says: > "For Information Elements with values > that are derived from fields of packets or from packet treatment and > for which the value may change from packet to packet within a single > Flow, the IPFIX information model defines that their value is > determined by the first packet observed for the corresponding Flow, > unless the description of the Information Element explicitly > specifies a different semantics." >=20 Uhm, I missed the description on RFC5102. It is determined by first packet. It might indicate determining by first received Flow Record. I wonder that first received Flow Record might not have the exact value of the first observed packet. In case of mediation, especially the spatial composition, the Flow Records are collected from a several observation points, it would be difficult to assure the exact value. Although this section needs to be rewritten, the topic will need to discuss at the later stage after problem statement. > > - DSCP=3D2, overwriting the latter value > > - DSCP=3D0, setting the 0 values, when finding unmatch in DSCP field. >=20 > These two options lead to invalid field value according to RFC5102. >=20 > > - deleting DSCP field from data structure >=20 > This is also possible. >=20 > > In my opinion, the topic seem not require the rule of non-key fields. > > But, it needs the discussion in next phase, not in problem statement > > phase. Even if the conclusion of discussion is no need of the rule, I > > expect that some document (maybe IPFIX aggregation) describes that > > non-key fields might result in ambiguous value. >=20 > There is no need for a new rule because RFC 5102 already specifies what > needs to be done! >=20 I am not sure just RFC5102 can be applied to mediation. I will discuss it with co-authors. Thank you! Best Regards, Atsushi KOBAYASHI From akoba@nttv6.net Mon Jun 15 04:44:53 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386B33A6CBD for ; Mon, 15 Jun 2009 04:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 kLM73BQyAw5B for ; Mon, 15 Jun 2009 04:44:52 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 682693A6C0A for ; Mon, 15 Jun 2009 04:44:51 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:3416:4e85:1504:25a5]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5FBibJA044078; Mon, 15 Jun 2009 20:44:38 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 15 Jun 2009 20:41:30 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A3563EA.4010906@net.in.tum.de> References: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE> <4A3563EA.4010906@net.in.tum.de> Message-Id: <20090615203640.B55E.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 15 Jun 2009 20:44:41 +0900 (JST) Cc: Sven Anderson , IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:44:53 -0000 Hi Gerhard, Sven, and all, In my opinion, although any networks, especially carrier network, transmit a large amount of VoIP and IPTV packets which are sensitive about network performance, there is no effective passive monitoring method regretfully. Although IPFIX/PSAMP covers the QoS measurement, its implementation has not appeared so far. I believe IPFIX can play a role for this work. We can try making the reference model of measurement infrastructure using current existing IPFIX/PSAMP specification, such as PSAMP selector, IPFIX-CONFIG, and mediation to encourage the implementation. It might start from problem statement, or come out some informational documents, and standard document describing some new information elements. Regards, Atsushi KOBAYASHI On Sun, 14 Jun 2009 22:56:10 +0200 Gerhard Muenz wrote: >=20 > Hi Sven, all, >=20 > I had a look at your paper. Indeed, it's an interesting use-case for > IPFIX which shows that the IPFIX protocol is flexible enough to > transport many different kinds of information. >=20 > However, I do not see any standardization issue here, apart from a > couple of new Information Elements. Also, the concept of Mediators is > not as essential for your purpose as you claim. The correlation of > different records can also be done at the Collector. >=20 > What about encryption? With IPSec, TLS, or DTLS, you won't be able to > extract any of the SIP fields with passive monitoring. This is a strong > limitation of the approach. >=20 > Regards, > Gerhard >=20 >=20 > Sven Anderson wrote: > >=20 > > Am 10.06.2009 um 12:49 schrieb Romascanu, Dan (Dan): > >=20 > >> You are correct about media recording. A session is however composed o= ut > >> of media and signaling (sometimes going on different paths). For the > >> signaling part IPFIX may be sufficient. > >=20 > > I just presented SIPFIX at the IM 2009 conference, which is an IPFIX > > based SIP monitoring scheme [1]. We will soon submit an Internet-Draft > > as well. They might be interested in it. > >=20 > > [1] http://sven.anderson.de/publications/sipfix.pdf > >=20 > > Sven > >=20 > >=20 > >> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Wednesday, June 10, 2009 12:50 PM > >>> To: Romascanu, Dan (Dan) > >>> Cc: IETF IPFIX Working Group > >>> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP > >>> > >>> On Wed, Jun 10, 2009 at 11:25:11AM +0200, Romascanu, Dan (Dan) wrote: > >>> > >>>> I threw a comment in this discussion that IPFIX may be a > >>> technology to > >>>> be considered for session recording. > >>>> > >>>> Any opinions or suggestions on this idea? > >>> > >>> They want to record complete media streams. IPFIX supports > >>> the export of flow summary records. I do not see a relation here. > >>> > >>> /js > >>> > >>> --=20 > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > >>> Fax: +49 421 200 3103 > >>> > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > >> > >=20 > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix >=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 NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dromasca@avaya.com Mon Jun 15 04:57:11 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F54F28C13F for ; Mon, 15 Jun 2009 04:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 qHup5gwj3ZxV for ; Mon, 15 Jun 2009 04:57:10 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1392B28C133 for ; Mon, 15 Jun 2009 04:57:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,222,1243828800"; d="scan'208";a="148552331" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Jun 2009 07:56:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jun 2009 07:56:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 13:56:10 +0200 Message-ID: In-Reply-To: <20090615203640.B55E.17391CF2@nttv6.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] FW: [dispatch] Session recording in SIP Thread-Index: Acntrs4yvPEvydH9QY6kdAr4oSzLUwAAUPMw References: <73A665B0-B98B-4086-8610-230B9320D98D@CS.Uni-Goettingen.DE><4A3563EA.4010906@net.in.tum.de> <20090615203640.B55E.17391CF2@nttv6.net> From: "Romascanu, Dan (Dan)" To: "Atsushi Kobayashi" , "Gerhard Muenz" Cc: Sven Anderson , IETF IPFIX Working Group Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 11:57:11 -0000 =20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org]=20 > On Behalf Of Atsushi Kobayashi > Sent: Monday, June 15, 2009 2:42 PM > To: Gerhard Muenz > Cc: Sven Anderson; IETF IPFIX Working Group > Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP >=20 >=20 > Hi Gerhard, Sven, and all, >=20 > In my opinion, although any networks, especially carrier=20 > network, transmit a large amount of VoIP and IPTV packets=20 > which are sensitive about network performance, there is no=20 > effective passive monitoring method regretfully. Although=20 > IPFIX/PSAMP covers the QoS measurement, its implementation=20 > has not appeared so far. I believe IPFIX can play a role for=20 > this work. >=20 See RFC 3611 and RFC 4710-4712.=20 Dan =20 From dromasca@avaya.com Mon Jun 15 05:56:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A6C3A6C86 for ; Mon, 15 Jun 2009 05:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 GU1qHsQpqtx8 for ; Mon, 15 Jun 2009 05:56:15 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id B11283A6898 for ; Mon, 15 Jun 2009 05:56:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,222,1243828800"; d="scan'208";a="173941293" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jun 2009 08:56:17 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Jun 2009 08:56:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:55:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 Thread-Index: AcntuJ7G+eQmqOzXRZaFRUlAoZxchg== From: "Romascanu, Dan (Dan)" To: "IETF IPFIX Working Group" Subject: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 12:56:16 -0000 Please find below the AD review for draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature enough to go to IETF Last Call. Unless there are any special comments or concerns I will send it to IETF Last Call by tomorrow.=20 Please consider the comments below together with the other IETF Last Call comments. The comments are divided into Technical and Editorial T1. There is not information concerning the impact on performance and capacity of the reporting and collecting processes. Should we expect any considerable impact on performance and/or capacity? If any implementation experience is available I would suggest that we record it.=20 E1. idnits complains about a number of IPR boilerplate issues and obsolete references issues:=20 tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): =20 ------------------------------------------------------------------------ ---- ** You're using the IETF Trust Provisions Section 6.b License Notice from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: =20 ------------------------------------------------------------------------ ---- No issues found here. Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 ------------------------------------------------------------------------ ---- No issues found here. Miscellaneous warnings: =20 ------------------------------------------------------------------------ ---- =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, = but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." Checking references for intended status: Informational =20 ------------------------------------------------------------------------ ---- =3D=3D Outdated reference: draft-ietf-psamp-sample-tech has been = published as RFC 5475 =3D=3D Outdated reference: draft-ietf-ipfix-architecture has been published as RFC 5470 =3D=3D Outdated reference: draft-ietf-ipfix-as has been published as = RFC 5472 =3D=3D Outdated reference: draft-ietf-psamp-protocol has been = published as RFC 5476 =3D=3D Outdated reference: draft-ietf-psamp-framework has been = published as RFC 5474 =3D=3D Outdated reference: draft-ietf-ipfix-reducing-redundancy has = been published as RFC 5473 =3D=3D Outdated reference: A later version (-01) exists of draft-stewart-tsvwg-sctpstrrst-00 Summary: 1 error (**), 8 warnings (=3D=3D), 0 comments (--) E2. PR-SCTP is not expanded at first occurrence in the Abstract=20 E3. I suggest to change the sentence in the IANA considerations as follows: According to the process defined in RFC 5202 IANA will allocate the dataRecordsRelability Information element defined in Section 4.2 From bclaise@cisco.com Tue Jun 16 00:48:47 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B676E3A690E for ; Tue, 16 Jun 2009 00:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrKUit5t21f6 for ; Tue, 16 Jun 2009 00:48:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 210FB3A69A6 for ; Tue, 16 Jun 2009 00:48:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5G7m9V4023991; Tue, 16 Jun 2009 09:48:09 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5G7m53G022126; Tue, 16 Jun 2009 09:48:05 +0200 (CEST) Message-ID: <4A374E34.40201@cisco.com> Date: Tue, 16 Jun 2009 09:48:04 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000204010805050007090801" Cc: "ipfix@ietf.org" , ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> reference X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 07:48:47 -0000 This is a multi-part message in MIME format. --------------000204010805050007090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, See this email: -------- Original Message -------- Subject: Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst Date: Mon, 27 Apr 2009 16:28:41 -0400 From: Lars Eggert To: tsvwg CC: draft-stewart-tsvwg-sctpstrrst@tools.ietf.org References: The consensus from SF has been confirmed. Authors, please submit the next version of this document as draft-ietf-tsvwg-sctp-strrst-00. Lars On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote: > Hi, > > during the WG meeting in SF, there was consensus to take on draft- > stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like > to confirm this result on the list. If you disagree with this > consensus decision, please speak up by April 15. > > Thanks, > Lars However, draft-stewart-tsvwg-sctpstrrst has not been posted yet Some background information from http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt Dan (AD): This draft cannot be a normative reference as long as it is not adopted by a the TSVWG. Suggestion: describe the mechanism in the normative part of the text and add an informative reference to the SCTP-RESET document. Once the document is included in the Transport WG charter it can be used as a normative reference. I propose that we keep our plan, without waiting for a dependency on the (future) TSV WG item. Are we still in sync? Regards, Benoit. > Please find below the AD review for > draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature > enough to go to IETF Last Call. Unless there are any special comments or > concerns I will send it to IETF Last Call by tomorrow. > > Please consider the comments below together with the other IETF Last > Call comments. The comments are divided into Technical and Editorial > > T1. There is not information concerning the impact on performance and > capacity of the reporting and collecting processes. Should we expect any > considerable impact on performance and/or capacity? If any > implementation experience is available I would suggest that we record > it. > > > > E1. idnits complains about a number of IPR boilerplate issues and > obsolete references issues: > > tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt: > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > http://trustee.ietf.org/license-info): > > ------------------------------------------------------------------------ > ---- > > ** You're using the IETF Trust Provisions Section 6.b License Notice > from > 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is > required now. (See http://trustee.ietf.org/license-info/) > > > Checking nits according to > http://www.ietf.org/ietf/1id-guidelines.txt: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > ------------------------------------------------------------------------ > ---- > > No issues found here. > > Miscellaneous warnings: > > ------------------------------------------------------------------------ > ---- > > == The document seems to lack a disclaimer for pre-RFC5378 work, but > was > first submitted before 10 November 2008. Should you add the > disclaimer? > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.). > > trust-12-feb-2009 Section 6.c.iii text: > "This document may contain material from IETF Documents or IETF > Contributions published or made publicly available before November > 10, 2008. The person(s) controlling the copyright in some of this > material may not have granted the IETF Trust the right to allow > modifications of such material outside the IETF Standards Process. > > Without obtaining an adequate license from the person(s) > controlling the copyright in such materials, this document may not > be modified outside the IETF Standards Process, and derivative > works of it may not be created outside the IETF Standards Process, > except to format it for publication as an RFC or to translate it > into languages other than English." > > > Checking references for intended status: Informational > > ------------------------------------------------------------------------ > ---- > > == Outdated reference: draft-ietf-psamp-sample-tech has been published > as > RFC 5475 > > == Outdated reference: draft-ietf-ipfix-architecture has been > published as > RFC 5470 > > == Outdated reference: draft-ietf-ipfix-as has been published as RFC > 5472 > > == Outdated reference: draft-ietf-psamp-protocol has been published as > RFC > 5476 > > == Outdated reference: draft-ietf-psamp-framework has been published > as RFC > 5474 > > == Outdated reference: draft-ietf-ipfix-reducing-redundancy has been > published as RFC 5473 > > == Outdated reference: A later version (-01) exists of > draft-stewart-tsvwg-sctpstrrst-00 > > > Summary: 1 error (**), 8 warnings (==), 0 comments (--) > > E2. PR-SCTP is not expanded at first occurrence in the Abstract > > E3. I suggest to change the sentence in the IANA considerations as > follows: According to the process defined in RFC 5202 IANA will allocate > the dataRecordsRelability Information element defined in Section 4.2 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------000204010805050007090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan,

See this email:

-------- Original Message --------
Subject: Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst
Date: Mon, 27 Apr 2009 16:28:41 -0400
From: Lars Eggert <lars.eggert@nokia.com>
To: tsvwg <tsvwg@ietf.org>
CC: draft-stewart-tsvwg-sctpstrrst@tools.ietf.org
References: <EF897F3E-88F2-4917-B02C-9507ADB2081E@nokia.com> 


The consensus from SF has been confirmed. Authors, please submit the  
next version of this document as draft-ietf-tsvwg-sctp-strrst-00.

Lars

On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote:

> Hi,
>
> during the WG meeting in SF, there was consensus to take on draft- 
> stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like  
> to confirm this result on the list. If you disagree with this  
> consensus decision, please speak up by April 15.
>
> Thanks,
> Lars

However, draft-stewart-tsvwg-sctpstrrst has not been posted yet

Some background information from http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt
Dan (AD): 
This draft cannot be a normative reference as long as it is
not adopted by a the TSVWG. Suggestion: describe the mechanism in the 
normative part of the text and add an informative reference to the 
SCTP-RESET document. Once the document is included in the Transport WG 
charter it can be used as a normative reference.
I propose that we keep our plan, without waiting for a dependency on the (future) TSV WG item.
Are we still in sync?

Regards, Benoit.
Please find below the AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
enough to go to IETF Last Call. Unless there are any special comments or
concerns I will send it to IETF Last Call by tomorrow. 

Please consider the comments below together with the other IETF Last
Call comments. The comments are divided into Technical and Editorial

T1. There is not information concerning the impact on performance and
capacity of the reporting and collecting processes. Should we expect any
considerable impact on performance and/or capacity? If any
implementation experience is available I would suggest that we record
it. 



E1. idnits complains about a number of IPR boilerplate issues and
obsolete references issues: 

tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
 
------------------------------------------------------------------------
----

  ** You're using the IETF Trust Provisions Section 6.b License Notice
from
     10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
     required now.  (See http://trustee.ietf.org/license-info/)


  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
 
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
 
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
 
------------------------------------------------------------------------
----

  == The document seems to lack a disclaimer for pre-RFC5378 work, but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.). 

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."


  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  == Outdated reference: draft-ietf-psamp-sample-tech has been published
as
     RFC 5475

  == Outdated reference: draft-ietf-ipfix-architecture has been
published as
     RFC 5470

  == Outdated reference: draft-ietf-ipfix-as has been published as RFC
5472

  == Outdated reference: draft-ietf-psamp-protocol has been published as
RFC
     5476

  == Outdated reference: draft-ietf-psamp-framework has been published
as RFC
     5474

  == Outdated reference: draft-ietf-ipfix-reducing-redundancy has been
     published as RFC 5473

  == Outdated reference: A later version (-01) exists of
     draft-stewart-tsvwg-sctpstrrst-00


     Summary: 1 error (**), 8 warnings (==), 0 comments (--)

E2. PR-SCTP is not expanded at first occurrence in the Abstract 

E3. I suggest to change the sentence in the IANA considerations as
follows: According to the process defined in RFC 5202 IANA will allocate
the dataRecordsRelability Information element defined in Section 4.2

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

--------------000204010805050007090801-- From dromasca@avaya.com Tue Jun 16 01:02:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A623A6957 for ; Tue, 16 Jun 2009 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CYimhzyAraC for ; Tue, 16 Jun 2009 01:02:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 8CAE73A6A17 for ; Tue, 16 Jun 2009 01:02:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,227,1243828800"; d="scan'208,217";a="174041593" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Jun 2009 04:02:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 16 Jun 2009 04:02:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EE58.BC40E66A" Date: Tue, 16 Jun 2009 10:02:03 +0200 Message-ID: In-Reply-To: <4A374E34.40201@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> reference Thread-Index: AcnuVtERTLExfM5qR76KhWy8t+O27QAAZ4tw References: <4A374E34.40201@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: ipfix@ietf.org, ipfix-chairs@tools.ietf.org Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> reference X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 08:02:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EE58.BC40E66A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can keep the plan. As it is an informational reference it will not be a blocking issue. .=20 =20 Dan ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Tuesday, June 16, 2009 10:48 AM To: Romascanu, Dan (Dan) Cc: Benoit Claise; Andrew Johnson; Paul Aitken; Gerhard Muenz; ipfix-chairs@tools.ietf.org; ipfix@ietf.org Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> reference =09 =09 Dan, =09 See this email: =09 =09 -------- Original Message --------=20 Subject: Re: [Tsvwg] WG adoption of draft-stewart-tsvwg-sctpstrrst=09 Date: Mon, 27 Apr 2009 16:28:41 -0400=09 From: Lars Eggert =09 To: tsvwg =09 CC: draft-stewart-tsvwg-sctpstrrst@tools.ietf.org=09 References: =09 The consensus from SF has been confirmed. Authors, please submit the =20 next version of this document as draft-ietf-tsvwg-sctp-strrst-00. =09 Lars =09 On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote: =09 > Hi, > > during the WG meeting in SF, there was consensus to take on draft-=20 > stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd like =20 > to confirm this result on the list. If you disagree with this =20 > consensus decision, please speak up by April 15. > > Thanks, > Lars However, draft-stewart-tsvwg-sctpstrrst has not been posted yet =09 Some background information from http://www.ietf.org/proceedings/08nov/minutes/ipfix.txt =09 Dan (AD):=20 This draft cannot be a normative reference as long as it is not adopted by a the TSVWG. Suggestion: describe the mechanism in the=20 normative part of the text and add an informative reference to the=20 SCTP-RESET document. Once the document is included in the Transport WG=20 charter it can be used as a normative reference.=20 =20 I propose that we keep our plan, without waiting for a dependency on the (future) TSV WG item. Are we still in sync? =09 Regards, Benoit. =09 Please find below the AD review for draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature enough to go to IETF Last Call. Unless there are any special comments or concerns I will send it to IETF Last Call by tomorrow.=20 =09 Please consider the comments below together with the other IETF Last Call comments. The comments are divided into Technical and Editorial =09 T1. There is not information concerning the impact on performance and capacity of the reporting and collecting processes. Should we expect any considerable impact on performance and/or capacity? If any implementation experience is available I would suggest that we record it.=20 =09 =09 =09 E1. idnits complains about a number of IPR boilerplate issues and obsolete references issues:=20 =09 tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt: =09 Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): =20 =09 ------------------------------------------------------------------------ ---- =09 ** You're using the IETF Trust Provisions Section 6.b License Notice from 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/) =09 =09 Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: =20 =09 ------------------------------------------------------------------------ ---- =09 No issues found here. =09 Checking nits according to http://www.ietf.org/ID-Checklist.html: =20 =09 ------------------------------------------------------------------------ ---- =09 No issues found here. =09 Miscellaneous warnings: =20 =09 ------------------------------------------------------------------------ ---- =09 =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.).=20 =09 trust-12-feb-2009 Section 6.c.iii text: "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. =09 Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English." =09 =09 Checking references for intended status: Informational =20 =09 ------------------------------------------------------------------------ ---- =09 =3D=3D Outdated reference: draft-ietf-psamp-sample-tech has been published as RFC 5475 =09 =3D=3D Outdated reference: draft-ietf-ipfix-architecture has been published as RFC 5470 =09 =3D=3D Outdated reference: draft-ietf-ipfix-as has been published as RFC 5472 =09 =3D=3D Outdated reference: draft-ietf-psamp-protocol has been published as RFC 5476 =09 =3D=3D Outdated reference: draft-ietf-psamp-framework has been published as RFC 5474 =09 =3D=3D Outdated reference: draft-ietf-ipfix-reducing-redundancy has been published as RFC 5473 =09 =3D=3D Outdated reference: A later version (-01) exists of draft-stewart-tsvwg-sctpstrrst-00 =09 =09 Summary: 1 error (**), 8 warnings (=3D=3D), 0 comments (--) =09 E2. PR-SCTP is not expanded at first occurrence in the Abstract=20 =09 E3. I suggest to change the sentence in the IANA considerations as follows: According to the process defined in RFC 5202 IANA will allocate the dataRecordsRelability Information element defined in Section 4.2 =09 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix =20 ------_=_NextPart_001_01C9EE58.BC40E66A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We can=20 keep the plan. As it is an informational reference it will not be a = blocking=20 issue. .
 
Dan

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Tuesday, June 16, 2009 10:48 AM
To: = Romascanu, Dan=20 (Dan)
Cc: Benoit Claise; Andrew Johnson; Paul Aitken; = Gerhard Muenz;=20 ipfix-chairs@tools.ietf.org; ipfix@ietf.org
Subject: Re: = [IPFIX] AD=20 Review of draft-ietf-ipfix-export-per-sctp-stream-02 ->=20 reference

Dan,

See this email:

-------- Original Message -------- 


The consensus from SF has been confirmed. Authors, please =
submit the =20
next version of this document as draft-ietf-tsvwg-sctp-strrst-00.

Lars

On 2009-4-8, at 11:12, Eggert Lars (Nokia-NRC/Espoo) wrote:

> Hi,
>
> during the WG meeting in SF, there was consensus to take on draft-=20
> stewart-tsvwg-sctpstrrst as a WG item in TSVWG. As always, we'd =
like =20
> to confirm this result on the list. If you disagree with this =20
> consensus decision, please speak up by April 15.
>
> Thanks,
> Lars

However, draft-stewart-tsvwg-sctpstrrst = has=20 not been posted yet

Some background information from http://w= ww.ietf.org/proceedings/08nov/minutes/ipfix.txt
Dan (AD):=20
This draft cannot be a normative reference as long as it is
not adopted by a the TSVWG. Suggestion: describe the mechanism in the=20
normative part of the text and add an informative reference to the=20
SCTP-RESET document. Once the document is included in the Transport WG=20
charter it can be used as a normative reference.=20
I propose that we keep our plan, without waiting = for a=20 dependency on the (future) TSV WG item.
Are we still in=20 sync?

Regards, Benoit.
Please find below the AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
enough to go to IETF Last Call. Unless there are any special comments or
concerns I will send it to IETF Last Call by tomorrow.=20

Please consider the comments below together with the other IETF Last
Call comments. The comments are divided into Technical and Editorial

T1. There is not information concerning the impact on performance and
capacity of the reporting and collecting processes. Should we expect any
considerable impact on performance and/or capacity? If any
implementation experience is available I would suggest that we record
it.=20



E1. idnits complains about a number of IPR boilerplate issues and
obsolete references issues:=20

tmp/draft-ietf-ipfix-export-per-sctp-stream-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/lic=
ense-info):
=20
------------------------------------------------------------------------
----

  ** You're using the IETF Trust Provisions Section 6.b License Notice
from
     10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is
     required now.  (See http://trustee.ietf.org/li=
cense-info/)


  Checking nits according to
http://www.ietf.org=
/ietf/1id-guidelines.txt:
=20
------------------------------------------------------------------------
----

     No issues found here.

  Checking nits according to http://www.ietf.org/ID-Ch=
ecklist.html:
=20
------------------------------------------------------------------------
----

     No issues found here.

  Miscellaneous warnings:
=20
------------------------------------------------------------------------
----

  =3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, =
but
was
     first submitted before 10 November 2008.  Should you add the
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/lic=
ense-info for more information.).=20

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."


  Checking references for intended status: Informational
=20
------------------------------------------------------------------------
----

  =3D=3D Outdated reference: draft-ietf-psamp-sample-tech has been =
published
as
     RFC 5475

  =3D=3D Outdated reference: draft-ietf-ipfix-architecture has been
published as
     RFC 5470

  =3D=3D Outdated reference: draft-ietf-ipfix-as has been published as =
RFC
5472

  =3D=3D Outdated reference: draft-ietf-psamp-protocol has been =
published as
RFC
     5476

  =3D=3D Outdated reference: draft-ietf-psamp-framework has been =
published
as RFC
     5474

  =3D=3D Outdated reference: draft-ietf-ipfix-reducing-redundancy has =
been
     published as RFC 5473

  =3D=3D Outdated reference: A later version (-01) exists of
     draft-stewart-tsvwg-sctpstrrst-00


     Summary: 1 error (**), 8 warnings (=3D=3D), 0 comments (--)

E2. PR-SCTP is not expanded at first occurrence in the Abstract=20

E3. I suggest to change the sentence in the IANA considerations as
follows: According to the process defined in RFC 5202 IANA will allocate
the dataRecordsRelability Information element defined in Section 4.2

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

------_=_NextPart_001_01C9EE58.BC40E66A-- From Saverio.Niccolini@nw.neclab.eu Tue Jun 16 01:40:43 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46463A692D for ; Tue, 16 Jun 2009 01:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JApjdrrc6lhk for ; Tue, 16 Jun 2009 01:40:43 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id C08A43A6917 for ; Tue, 16 Jun 2009 01:40:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 8C66F2C01C9AF for ; Tue, 16 Jun 2009 10:39:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4qmDVAF88sT for ; Tue, 16 Jun 2009 10:39:36 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6DAC72C01C8EC for ; Tue, 16 Jun 2009 10:39:31 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 16 Jun 2009 10:39:31 +0200 Message-ID: <547F018265F92642B577B986577D671C973FD9@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [IPFIX] FW: [dispatch] Session recording in SIP Thread-Index: AcnuXfevPAWFtBt8TKuHg2KzaRW9Jw== From: "Saverio Niccolini" To: Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 08:40:43 -0000 Regarding the SIPFIX draft Sven was talking about: we will submit it shortly, the idea is basically as Kobayashi-san was hinting: -- trying to define the problem statement and requirements since we see the need of starting to use the current IPFIX definitions for monitoring VoIP systems What can come from there? an informational document trying to define the problem space and maybe moving from there a standard deifntion of new VoIP-specific IEs. Just my two cents (just with a couple of days to see the draft). Cheers, Saverio > Hi Gerhard, Sven, and all, > > In my opinion, although any networks, especially carrier network, > transmit a large amount of VoIP and IPTV packets which are sensitive > about network performance, there is no effective passive monitoring > method regretfully. Although IPFIX/PSAMP covers the QoS measurement, = its > implementation has not appeared so far. I believe IPFIX can play a = role > for this work. > > We can try making the reference model of measurement infrastructure > using current existing IPFIX/PSAMP specification, such as PSAMP = selector, > IPFIX-CONFIG, and mediation to encourage the implementation. > > It might start from problem statement, or come out some informational > documents, and standard document describing some new information > elements. > > Regards, > Atsushi KOBAYASHI =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-118 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 saverio.niccolini@nw.neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 =A0=20 From akoba@nttv6.net Tue Jun 16 02:42:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7331328C12A for ; Tue, 16 Jun 2009 02:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 XRqkSe5QXlWM for ; Tue, 16 Jun 2009 02:42:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id AC47B3A6AF0 for ; Tue, 16 Jun 2009 02:42:30 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:4026:b5bd:2194:2720]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5G9gcMU069409; Tue, 16 Jun 2009 18:42:39 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 16 Jun 2009 18:39:24 +0900 From: Atsushi Kobayashi To: Motonori Shindo In-Reply-To: <20090616.152845.26766196.mshindo@mshindo.net> References: <20090610214015.6E56.17391CF2@nttv6.net> <20090616.152845.26766196.mshindo@mshindo.net> Message-Id: <20090616153237.B582.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 16 Jun 2009 18:42:39 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 09:42:32 -0000 Shindo-san, Thank you! Please see commments inline. On Tue, 16 Jun 2009 15:28:45 +0900 (JST) Motonori Shindo wrote: > Atsushi, > > I went through the draft-ietf-ipfix-mediators-problem-statement-03 and > came up with some comments and questions as follows: > > > etc.), and data format. For example, probes and switches cannot > > retrieve packet property information from a route table. > ^^^^^^^^^^^ > > Here you refer to it as a "route table" while referring to the same > thing as "routing table" in another place. It's better to be > consistent. I personally prefer "routing table". Ok. I unify into reference "routing table". > > > 5.1. Adjusting Flow Granularity > > > > The simplest types of Flows are those comprised of packets all having > > a fixed IP-quintuple of protocol, source and destination IP > > addresses, and source and destination port numbers. > > This is a bit cosmetic point, but I think 5-tuple (src/dst ip address, > src/dst port number and transport protocol) is more widely accepted as > a flow than the quintuple you mentioned. > You are right. 5-tuple is more preferable. > > In the case where the Original Exporter contains a Metering > > Process that creates fixed tuple Flow Records (no possibility to > > change the Flow Keys), ... ^^^^^^^^^^^ > > You probably meant "ability" ? > Yes. > > 5.4. Time Composition > > > > Time composition is defined as the aggregation of consecutive Data > > Records with identical Flow Keys. It leads to the same output as > > setting a longer active interval ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > "It has the same effect" is more intuitive for me. > > > 5.6. Data Record Anonymization > > I would like to point out that ifIndex (ingressInterface and > egressInterface) can sometimes be subject to anonymization. Suppose an > ISP is providing a traffic monitoring service to end customers who > have their own IPFIX Collector. In such a case, ISP might not wish to > disclose the interface information of their routers/switches to end > customers even if it is simply an integer value. > Good example. A whole set of integer values related to ifIndex might be fingerprint of routers, or switches. Someone can deduces its vendor, or software version. > IPFIX Proxy best fits into this situation, where ifIndex information > is anonymized or even completely suppressed. > It is IPFIX Masquerading Proxy. ;-) I will add the following sentence. "As another example, when ISP provides a traffic monitoring service to end customers by their own Exporters, even in case of exporting interface index fields, network administrators take care of anonymizing its fields to avoid disclosing the vulnerability." > > Original Exporter and Collector. If a unreliable transport > > protocol such as UDP is used, a legacy exporting device exports > > Data Records to a nearby IPFIX Proxy through UDP, and then an > > IPFIX Proxy could reliably export them to the top IPFIX Collector > > through SCTP. ^^^^^^^^^^^^^^^^^^^ > > This is the first occurrence of the concept "top" for Collectors and > there are a few more places referring to the same concept (e.g. "top > level Collector"). It should be clearly defined before you refer to > this concept. > As Gerhalz pointed out, I will remove "top" and "top level". > > Regarding huge storage requirement, one possible implementation > > uses a decentralized set of Collectors. If administrators need to > > retrieve specific Data Records, these Collectors would need to be > > equipped with IPFIX Mediations. > > I don't quite understand this paragraph. Will you be a bit more > elaborate? > One possible implementation adopts distributed structure of Collectors to increase the storage capacity. Example is a parallel structure in which Collectors are located near Exporters. If some application servers need to communicate with these Collectors, these Collectors would have the IPFIX Mediation. > > limited. Therefore, even if multiple Flow Records type should be of > > interest to the Collector (Flow Records in both directions, Flow > > Records before and after WAN optimization techniques, performance > > metrics associated with the Flow Records exported on regular > > interval), > > Appending ", etc." in the parentheses would be better because this is > not an exhaustive list of examples. > Ok. > > and Exporter#2, which are the Original Exporters. The IPFIX Mediator > > must have a specific way to the Original Exporter IP address to the > > IPFIX Collector. > > Do you mean that "The IPFIX Mediator must have a specific way to tell > the Original Exporter IP address to the IPFIX Collector."? > Yes. It's lack of word. I will improve it, as follows. "The IPFIX Mediator must be able to notify the Collector about the Original Exporter IP address of the Original Exporter." Regards, Atsushi KOBAYASHI From bclaise@cisco.com Tue Jun 16 13:52:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9478028C1A9 for ; Tue, 16 Jun 2009 13:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 QpFQ7hG-i9b2 for ; Tue, 16 Jun 2009 13:52:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8748728C123 for ; Tue, 16 Jun 2009 13:52:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5GKpwgY022738; Tue, 16 Jun 2009 22:51:58 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5GKpulY027720; Tue, 16 Jun 2009 22:51:56 +0200 (CEST) Message-ID: <4A3805EC.3010702@cisco.com> Date: Tue, 16 Jun 2009 22:51:56 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:52:49 -0000 Dan, > Please find below the AD review for > draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature > enough to go to IETF Last Call. Unless there are any special comments or > concerns I will send it to IETF Last Call by tomorrow. > > Please consider the comments below together with the other IETF Last > Call comments. The comments are divided into Technical and Editorial > > T1. There is not information concerning the impact on performance and > capacity of the reporting and collecting processes. Should we expect any > considerable impact on performance and/or capacity? If any > implementation experience is available I would suggest that we record > it. > Collecting information from the authors of draft-stewart-tsvwg-sctpstrrst and draft-ietf-ipfix-export-per-sctp-stream-02, here are the conclusions: * We were not too sure what is meant by "performance and capacity" in this context. * If the question is about: What's the impact of additional SCTP streams in an existing session versus opening a new SCTP session? The impact is minor: - You have of course a message exchange to add the streams. - You end up adding 16-24 bytes per stream. - It is more lightweight to set up additional streams compared to setting up a new association. The only thing that comes into my mind is throughput which * If the question is about the throughput that could be impaired by processing overhead and message overhead. - With respect of processing overhead, I have no idea how the utilization of a large number of streams influences the performance of the SCTP socket. I could imagine that a lot of state information must be stored. - With respect of message overhead, we can say that the fact that we discourage multiplexing templates and data records of different template ids may lead to a larger message overhead. If the data record rate is low for a specific template, the exporting process might not be able to optimally fill the IPFIX messages. Hence, we have more overhead due to additional IPFIX message headers and SCTP chunk headers. Is this what you have in mind? Regards, Benoit. From bclaise@cisco.com Tue Jun 16 15:11:50 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B214A28C1AA for ; Tue, 16 Jun 2009 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cFEoqlKorMU for ; Tue, 16 Jun 2009 15:11:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id EA4713A6A6F for ; Tue, 16 Jun 2009 15:11:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5GMBvJh028129; Wed, 17 Jun 2009 00:11:57 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5GMBrKZ020143; Wed, 17 Jun 2009 00:11:54 +0200 (CEST) Message-ID: <4A3818A9.90304@cisco.com> Date: Wed, 17 Jun 2009 00:11:53 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090610211008.6E53.17391CF2@nttv6.net> <4A34D206.4070704@net.in.tum.de> <20090615163232.B555.17391CF2@nttv6.net> In-Reply-To: <20090615163232.B555.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------010106000805020605060804" Cc: "Rony Gotesdyner \(rgotesdy\)" , "Chris Bucci \(cbucci\)" , Frederick Serr , IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 22:11:50 -0000 This is a multi-part message in MIME format. --------------010106000805020605060804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Kobayashi-san, Gerhard, > Dear Gerhard, and all, > > >> Dear Atsushi, all, >> >> Actually, I was surprised and a little bit disappointed that Jürgen and >> me were the only ones who answered to the WGLC - or did I miss something? >> > > I have received comments from the Juergen and you. It is too few. :-( > Actually we also received some feedback from Motonori Shindo. I received feedback from 3 co-workers on the previous version (nothing was sent on the list). I've asked them if they could re-read this version as well. Regards, Benoit. > I expect the other members did not send a message yet in list. > > >> Even though this is "only" an informational problem statement, I think >> it would be useful to have more reviewers and more discussion. >> Otherwise, it looks like a lack of interest in IPFIX mediation - and no >> interest means that there is no need for a standard. >> > > Gerhard, thank you. > > Anyone's comments are welcome. > Let me know your comments and feedback. > > Please find comments inline: > > >>>> In my opinion, the terminology related to Mediation must be rethought >>>> another time before publishing this problem statement as an RFC. >>>> The current terminology section defines the following terms: >>>> >>>> *IPFIX Mediation* >>>> = a function >>>> >>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>> = specific types of IPFIX Mediation >>>> >>>> >>> Do you suggest that they are a specific type of device? >>> >>> e.g. >>> >>> IPFIX Proxy >>> >>> An IPFIX Proxy is a type of IPFIX Mediator that relays incoming >>> ^^^^^^^^ >>> Transport Sessions to one or multiple Collectors. >>> >>> Your points are reasonable for me, the further discussion with co-authors >>> is needed to address it. >>> >>> >>>> *IPFIX Mediator* >>>> = devices that implements IPFIX Mediation >>>> >>>> >>> If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are >>> defined as the devices, I think that the following issues can be solved. >>> >> Yes, I think that IPFIX Concentrator, Proxy, etc. should be defined as >> devices. IPFIX Mediator can be an umbrella term for all of them. >> >> This change will result in a couple of further changes in the text. >> E.g. in the introduction: >> While the IPFIX requirements defined in [RFC3917] mention an >> _intermediate function_, such as an IPFIX Proxy or an IPFIX >> Concentrator, there are no documents defining the function called >> IPFIX Mediation. >> "intermediate function" needs to be replaced, e.g. by "device"? >> > > Oh, yes. > > >>>> This terminology has several flaws: >>>> - On the one hand, you have troubles to distinguish between IPFIX >>>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>> - On the other hand, the terms do not fit into the current terminology >>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >>>> talk about the instantiation of a specific function. >>>> >>> I will add "XXX Process" terms in framework draft rather than problem >>> statement. It seems better that the problem statement draft does not >>> include the "XXX Process" terms illustrating the implementation. >>> >>> >>>> - Finally, the definition of IPFIX Concentrator does not correspond to >>>> the usage of this term in RFC3917. There, a Concentrator is a device, >>>> not a function. >>>> >>>> I like the approach that has been chosen by PSAMP. There, we distinguish >>>> between "Selectors" (which are abstract selection functions) and >>>> "Selection Processes" (which are instantiations of Selectors). Selection >>>> Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest >>>> to apply this approach to Mediation as well. >>>> >>>> In the case of Mediation, we would have abstract Mediation Functions >>>> (anonymization, aggregation, sampling, proxy, distribution). These would >>>> be instantiated in a Mediation Process. A Mediation Process can then be >>>> part of an Exporter (Original Exporter), Collector, or Mediator. >>>> >>> Yes. We can describe the your suggestion as "Intermediate Process" in >>> framework draft. >>> >> Ok. >> >> >>>>> The recent continued IP traffic growth has been overwhelming the >>>>> >>>> "The sustained growth of IP traffic..." ? >>>> >>>> >>>>> measurement system capacity, and multi-purposing applications, along >>>>> >>>> multi-purpose? >>>> >>>> Yet, it is not clear to me what you mean. >>>> >>>> >>> I means that implementation of multiple traffic measurements, such as >>> QoS measurement and traffic engineering, have been contributing to a >>> complex situation, and executing it with the heterogeneous environments >>> also results in further more complex. >>> >>> >>>>> with the heterogeneous environments, have further been contributing >>>>> to a complex situation. >>>>> >> Ok, so maybe two sentences: >> "The sustained growth of IP traffic has been overwhelming measurement >> system capacities. Furthermore, a large variety of applications (e.g., >> QoS measurement, traffic engineering, security monitoring) and the >> deployment of IP traffic measurements in heterogeneous environments have >> been increasing the demand and complexity of IP traffic measurements." >> >> > > Yes. fine. > > >>>>> The following sub-sections explain different >>>>> problems in more details. >>>>> >>>>> 4.1. Coping with IP Traffic Growth >>>>> >>>>> Enterprise or service provider networks already have multiple 10 Gb/s >>>>> links, their total traffic exceeding 100 Gb/s. In the near future, >>>>> broadband users' traffic will increase by approximately 40% every >>>>> year according to [TRAFGRW]. When operators monitor traffic of 500 >>>>> Gb/s with a 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. >>>>> >>>>> To deal with this problem, current data reduction techniques, such as >>>>> Sampling, Filtering, Data Records aggregation have been generally >>>>> >>>> For me, "aggregation" refers to the semantic level of exported >>>> information. Therefore, I would call it "flow aggregation" instead of >>>> "Data Record aggregation". >>>> >>> Does the flow in "flow aggregation" indicate general 7-tuple flow in >>> NetFlow? It needs the distinction between flow in NetFlow and Flow in >>> IPFIX, since the Flow term in IPFIX covers an aggregated Flow. >>> >> Well, to what kind of aggregation do you want to refer in this sentence? >> What kind of aggregation is currently implemented apart from flow >> aggregation in the sense of aggregating 7-tuple flows? >> >> > > Currently, we can use implemented NetFlow version 8 or flexible > aggregation based on NetFlow version 9. As you mention, I should > describe it more generally. > > >> To be more general, you could write: >> "To deal with this problem, current data reduction techniques, such as >> Sampling, Filtering, aggregation of measurement data,..." >> >> >>>>> implemented on Exporters. Note that Sampling technique leads to >>>>> etc.), and data format. For example, probes and switches cannot >>>>> retrieve packet property information from a route table. >>>>> >>>> Do you mean AS information? >>>> >>>> >>> Yes. >>> >>> "For example, probes and switches cannot retrieve some Derived Packet >>> Properties in [RFC5102] from a route table." >>> >> "..., such as the autonomous systems of source and destination IP >> addresses." ? >> >> >>>>> * Treatment from the correlation of Data Records with the same >>>>> >>>> IPFIX Flow Records? >>>> >>>> >>> In that case, both of IPFIX Flow Records and PSAMP Packet Reports can be >>> applied. >>> >> Hm, Packet Reports do not have "Flow Key(s)" as mentioned in the >> sentence, do they? >> >> >>>>> Flow Key(s) observed at incoming/outgoing interfaces. Examples >>>>> are the rate-limiting ratio, the compression ratio, the >>>>> optimization ratio, etc. >>>>> >>>>> 5.4. Time Composition >>>>> >>>>> Time composition is defined as the aggregation of consecutive Data >>>>> >>>> in this case: IPFIX Flow Records >>>> >>>> >>> Aggregation (including the Time composition) can be applied to both of >>> input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this >>> case keeps "Data Records". >>> >> Same as above: PSAMP Packet Reports does not have Flow Key(s). >> So, the sentence only works for Flow Records. >> > > OK. > > I can use "defined common properties" instead of "Flow Key(s)" to apply > to the Flow and Packet Report. > > > >>>>> Records with identical Flow Keys. It leads to the same output as >>>>> >>>>> For example, an IPFIX Distributor must maintain the state of the >>>>> incoming Transport Sessions in order to manage the Template ID on its >>>>> outgoing Transport Session correctly. In the following figure, even >>>>> >>>> The rest of the paragraph is unclear: >>>> >>>> >>>>> if the Transport Session from Exporter re-initializes, the IPFIX >>>>> Distributor must manage the association of Template IDs in specific >>>>> Transport Session. Typically, when the Exporter#1 Transport Session >>>>> re-initialized, the Template ID 256 replaced the previous Template ID >>>>> 258, while the IPFIX Distributor will keep exporting the Template ID >>>>> 256 to the Collector. >>>>> >>>> Are all Templates identical? Or how comes that there is only one >>>> Template in the outgoing Transport Session? >>>> >>>> Please explain better. >>>> >>>> >>> I image that IPFIX Distributor exports 3 templates including >>> template ID 256, template ID 257, and template ID 258. All templates are >>> kept the template ID value from input Transport Session. Even when the >>> Exporter 1 is re-initialized and the template 258 is replaced with 256, IPFIX >>> Distributor must avoid the duplication of template ID values. >>> >> The mapping of incoming Template IDs to outgoing Template IDs is not >> clear from the figure. Maybe a table would help to explain. >> And again: Exporter 1's Templates 256 and 258 are identical, right? >> >> > > Yes. > > > >>> I will improve the phrase and the following figure. >>> >>> >>>>> .----------. OLD: Template ID 258 >>>>> |IPFIX | NEW: Template ID 256 >>>>> |Exporter#1|----+ >>>>> | | | >>>>> '----------' X >>>>> .----------. | .-----------. .----------. >>>>> |IPFIX | '---------->| | | | >>>>> |Exporter#2|--------------->|IPFIX |-------X------>|IPFIX | >>>>> | |Template ID 257 |Distributor|Template ID 256| Collector| >>>>> '----------' +---------->| | | | >>>>> .----------. | '-----------' '----------' >>>>> |IPFIX | | >>>>> |Exporter#3|----' >>>>> | | Template ID 256 >>>>> '----------' >>>>> >>>>> Figure C: Relaying from Multiple Transport Sessions to Single >>>>> Transport Session. >>>>> >>>>> 6.8. Consideration for Aggregation >>>>> >>>>> In case of Flow Key aggregation, Time Composition, and Spatial >>>>> Composition, there are the following considerations: >>>>> >>>>> o Aggregation rule for non Flow Keys >>>>> >>>> "non Flow Keys" => "non-key fields" >>>> >>>> >>>>> There are no obvious rules of non Flow Keys. For example, if an >>>>> >>>> "non Flow Keys" => "non-key fields" >>>> >>>> >>>>> IPFIX Mediation receives two Flow Records with different DSCP >>>>> values, and this DSCP field is not a Flow Key, those two Flow >>>>> Records can be aggregated based on the Flow Keys value. However, >>>>> there is no rules for what the DSCP value should be for the >>>>> aggregated Data Record. Potential solutions are: the value of >>>>> >>>> Actually, there is a rule! >>>> Unless specified differently, the value of the first packet must be >>>> included in the record. Hence, as long as timestamps are present and >>>> allow to determine which one of the Flow Records includes the earliest >>>> packet, the decision is evident! >>>> >>>> >>> I don't undestand your points. >>> >>> If receiving two Flow Records ( earlier one with DSCP=1 and later one >>> with DSCP=2), we can choose the several implementations as follows. >>> - DSCP=1, keeping the earliest value >>> >> This is the correct solution! >> >> Because RFC5102 says: >> "For Information Elements with values >> that are derived from fields of packets or from packet treatment and >> for which the value may change from packet to packet within a single >> Flow, the IPFIX information model defines that their value is >> determined by the first packet observed for the corresponding Flow, >> unless the description of the Information Element explicitly >> specifies a different semantics." >> >> > > Uhm, I missed the description on RFC5102. > It is determined by first packet. It might indicate determining by first > received Flow Record. I wonder that first received Flow Record might not > have the exact value of the first observed packet. In case of > mediation, especially the spatial composition, the Flow Records are > collected from a several observation points, it would be difficult to > assure the exact value. > > Although this section needs to be rewritten, the topic will need to discuss > at the later stage after problem statement. > > >>> - DSCP=2, overwriting the latter value >>> - DSCP=0, setting the 0 values, when finding unmatch in DSCP field. >>> >> These two options lead to invalid field value according to RFC5102. >> >> >>> - deleting DSCP field from data structure >>> >> This is also possible. >> >> >>> In my opinion, the topic seem not require the rule of non-key fields. >>> But, it needs the discussion in next phase, not in problem statement >>> phase. Even if the conclusion of discussion is no need of the rule, I >>> expect that some document (maybe IPFIX aggregation) describes that >>> non-key fields might result in ambiguous value. >>> >> There is no need for a new rule because RFC 5102 already specifies what >> needs to be done! >> >> > > I am not sure just RFC5102 can be applied to mediation. > > I will discuss it with co-authors. Thank you! > > Best Regards, > Atsushi KOBAYASHI > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > --------------010106000805020605060804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kobayashi-san, Gerhard, 
Dear Gerhard, and all,

  
Dear Atsushi, all,

Actually, I was surprised and a little bit disappointed that Jürgen and
me were the only ones who answered to the WGLC - or did I miss something?
    

I have received comments from the Juergen and you. It is too few. :-(
Actually we also received some feedback from Motonori Shindo.
I received feedback from 3 co-workers on the previous version (nothing was sent on the list).
I've asked them if they could re-read this version as well.

Regards, Benoit.
I expect the other members did not send a message yet in list.

  
Even though this is "only" an informational problem statement, I think
it would be useful to have more reviewers and more discussion.
Otherwise, it looks like a lack of interest in IPFIX mediation - and no
interest means that there is no need for a standard.
    

Gerhard, thank you.

Anyone's comments are welcome.
Let me know your comments and feedback. 

Please find comments inline:

  
In my opinion, the terminology related to Mediation must be rethought
another time before publishing this problem statement as an RFC.
The current terminology section defines the following terms:

*IPFIX Mediation*
= a function

*IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
= specific types of IPFIX Mediation

        
Do you suggest that they are a specific type of device?

e.g.

   IPFIX Proxy

      An IPFIX Proxy is a type of IPFIX Mediator that relays incoming
                                        ^^^^^^^^ 
      Transport Sessions to one or multiple Collectors. 

Your points are reasonable for me, the further discussion with co-authors
is needed to address it.

      
*IPFIX Mediator*
= devices that implements IPFIX Mediation

        
If "IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor" are
defined as the devices, I think that the following issues can be solved.
      
Yes, I think that IPFIX Concentrator, Proxy, etc. should be defined as
devices. IPFIX Mediator can be an umbrella term for all of them.

This change will result in a couple of further changes in the text.
E.g. in the introduction:
    While the IPFIX requirements defined in [RFC3917] mention an
    _intermediate function_, such as an IPFIX Proxy or an IPFIX
    Concentrator, there are no documents defining the function called
    IPFIX Mediation.
"intermediate function" needs to be replaced, e.g. by "device"?
    

Oh, yes.

  
This terminology has several flaws:
- On the one hand, you have troubles to distinguish between IPFIX
Mediation implemented at an "Original Exporter" and IPFIX Mediation
implemented at a "separate IPFIX Mediator/Concentrator/...".
- On the other hand, the terms do not fit into the current terminology
scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
talk about the instantiation of a specific function.
        
I will add "XXX Process" terms in framework draft rather than problem
statement. It seems better that the problem statement draft does not
include the "XXX Process" terms illustrating the implementation.

      
- Finally, the definition of IPFIX Concentrator does not correspond to
the usage of this term in RFC3917. There, a Concentrator is a device,
not a function.

I like the approach that has been chosen by PSAMP. There, we distinguish
between "Selectors" (which are abstract selection functions) and
"Selection Processes" (which are instantiations of Selectors). Selection
Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest
to apply this approach to Mediation as well.

In the case of Mediation, we would have abstract Mediation Functions
(anonymization, aggregation, sampling, proxy, distribution). These would
be instantiated in a Mediation Process. A Mediation Process can then be
part of an Exporter (Original Exporter), Collector, or Mediator.
        
Yes. We can describe the your suggestion as "Intermediate Process" in
framework draft. 
      
Ok.

    
   The recent continued IP traffic growth has been overwhelming the
          
"The sustained growth of IP traffic..." ?

        
   measurement system capacity, and multi-purposing applications, along
          
multi-purpose?

Yet, it is not clear to me what you mean.

        
I means that implementation of multiple traffic measurements, such as
QoS measurement and traffic engineering, have been contributing to a
complex situation, and executing it with the heterogeneous environments
also results in further more complex.

      
   with the heterogeneous environments, have further been contributing
   to a complex situation.  
          
Ok, so maybe two sentences:
"The sustained growth of IP traffic has been overwhelming measurement
system capacities. Furthermore, a large variety of applications (e.g.,
QoS measurement, traffic engineering, security monitoring) and the
deployment of IP traffic measurements in heterogeneous environments have
been increasing the demand and complexity of IP traffic measurements."

    

Yes. fine.

  
The following sub-sections explain different
   problems in more details.

4.1.  Coping with IP Traffic Growth

   Enterprise or service provider networks already have multiple 10 Gb/s
   links, their total traffic exceeding 100 Gb/s.  In the near future,
   broadband users' traffic will increase by approximately 40% every
   year according to [TRAFGRW].  When operators monitor traffic of 500
   Gb/s with a 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.

   To deal with this problem, current data reduction techniques, such as
   Sampling, Filtering, Data Records aggregation have been generally
          
For me, "aggregation" refers to the semantic level of exported
information. Therefore, I would call it "flow aggregation" instead of
"Data Record aggregation".
        
Does the flow in "flow aggregation" indicate general 7-tuple flow in
NetFlow? It needs the distinction between flow in NetFlow and Flow in
IPFIX, since the Flow term in IPFIX covers an aggregated Flow.
      
Well, to what kind of aggregation do you want to refer in this sentence?
What kind of aggregation is currently implemented apart from flow
aggregation in the sense of aggregating 7-tuple flows?

    

Currently, we can use implemented NetFlow version 8 or flexible
aggregation based on NetFlow version 9. As you mention, I should
describe it more generally.

  
To be more general, you could write:
"To deal with this problem, current data reduction techniques, such as
Sampling, Filtering, aggregation of measurement data,..."

    
   implemented on Exporters.  Note that Sampling technique leads to
   etc.), and data format.  For example, probes and switches cannot
   retrieve packet property information from a route table.
          
Do you mean AS information?

        
Yes. 

"For example, probes and switches cannot retrieve some Derived Packet
Properties in [RFC5102] from a route table."
      
"..., such as the autonomous systems of source and destination IP
addresses." ?

    
      *  Treatment from the correlation of Data Records with the same
          
IPFIX Flow Records?

        
In that case, both of IPFIX Flow Records and PSAMP Packet Reports can be
applied.
      
Hm, Packet Reports do not have "Flow Key(s)" as mentioned in the
sentence, do they?

    
         Flow Key(s) observed at incoming/outgoing interfaces.  Examples
         are the rate-limiting ratio, the compression ratio, the
         optimization ratio, etc.
          
5.4.  Time Composition

   Time composition is defined as the aggregation of consecutive Data
          
in this case: IPFIX Flow Records

        
Aggregation (including the Time composition) can be applied to both of
input IPFIX Flow Records and input PSAMP Packet Reports. Hence, this
case keeps "Data Records".
      
Same as above: PSAMP Packet Reports does not have Flow Key(s).
So, the sentence only works for Flow Records.
    

OK.

I can use "defined common properties" instead of "Flow Key(s)" to apply
to the Flow and Packet Report.


  
   Records with identical Flow Keys.  It leads to the same output as
          
   For example, an IPFIX Distributor must maintain the state of the
   incoming Transport Sessions in order to manage the Template ID on its
   outgoing Transport Session correctly.  In the following figure, even
          
The rest of the paragraph is unclear:

        
   if the Transport Session from Exporter re-initializes, the IPFIX
   Distributor must manage the association of Template IDs in specific
   Transport Session.  Typically, when the Exporter#1 Transport Session
   re-initialized, the Template ID 256 replaced the previous Template ID
   258, while the IPFIX Distributor will keep exporting the Template ID
   256 to the Collector.
          
Are all Templates identical? Or how comes that there is only one
Template in the outgoing Transport Session?

Please explain better.

        
I image that IPFIX Distributor exports 3 templates including
template ID 256, template ID 257, and template ID 258. All templates are
kept the template ID value from input Transport Session. Even when the
Exporter 1 is re-initialized and the template 258 is replaced with 256, IPFIX
Distributor must avoid the duplication of template ID values.
      
The mapping of incoming Template IDs to outgoing Template IDs is not
clear from the figure. Maybe a table would help to explain.
And again: Exporter 1's Templates 256 and 258 are identical, right?

    

Yes.


  
I will improve the phrase and the following figure.

      
   .----------. OLD: Template ID 258
   |IPFIX     | NEW: Template ID 256
   |Exporter#1|----+
   |          |    |
   '----------'    X
   .----------.    |           .-----------.               .----------.
   |IPFIX     |    '---------->|           |               |          |
   |Exporter#2|--------------->|IPFIX      |-------X------>|IPFIX     |
   |          |Template ID 257 |Distributor|Template ID 256| Collector|
   '----------'    +---------->|           |               |          |
   .----------.    |           '-----------'               '----------'
   |IPFIX     |    |
   |Exporter#3|----'
   |          | Template ID 256
   '----------'

   Figure C: Relaying from Multiple Transport Sessions to Single
   Transport Session.
          
6.8.  Consideration for Aggregation

   In case of Flow Key aggregation, Time Composition, and Spatial
   Composition, there are the following considerations:

   o  Aggregation rule for non Flow Keys
          
"non Flow Keys" => "non-key fields"

        
      There are no obvious rules of non Flow Keys.  For example, if an
          
"non Flow Keys" => "non-key fields"

        
      IPFIX Mediation receives two Flow Records with different DSCP
      values, and this DSCP field is not a Flow Key, those two Flow
      Records can be aggregated based on the Flow Keys value.  However,
      there is no rules for what the DSCP value should be for the
      aggregated Data Record.  Potential solutions are: the value of
          
Actually, there is a rule!
Unless specified differently, the value of the first packet must be
included in the record. Hence, as long as timestamps are present and
allow to determine which one of the Flow Records includes the earliest
packet, the decision is evident!

        
I don't undestand your points.

If receiving two Flow Records ( earlier one with DSCP=1 and later one
with DSCP=2), we can choose the several implementations as follows.
- DSCP=1, keeping the earliest value
      
This is the correct solution!

Because RFC5102 says:
   "For Information Elements with values
   that are derived from fields of packets or from packet treatment and
   for which the value may change from packet to packet within a single
   Flow, the IPFIX information model defines that their value is
   determined by the first packet observed for the corresponding Flow,
   unless the description of the Information Element explicitly
   specifies a different semantics."

    

Uhm, I missed the description on RFC5102.
It is determined by first packet. It might indicate determining by first
received Flow Record. I wonder that first received Flow Record might not
have the exact value of the first observed packet. In case of
mediation, especially the spatial composition, the Flow Records are
collected from a several observation points, it would be difficult to
assure the exact value.

Although this section needs to be rewritten, the topic will need to discuss
at the later stage after problem statement.

  
- DSCP=2, overwriting the latter value
- DSCP=0, setting the 0 values, when finding unmatch in DSCP field.
      
These two options lead to invalid field value according to RFC5102.

    
- deleting DSCP field from data structure
      
This is also possible.

    
In my opinion, the topic seem not require the rule of non-key fields.
But, it needs the discussion in next phase, not in problem statement
phase. Even if the conclusion of discussion is no need of the rule, I
expect that some document (maybe IPFIX aggregation) describes that
non-key fields might result in ambiguous value.
      
There is no need for a new rule because RFC 5102 already specifies what
needs to be done!

    

I am not sure just RFC5102 can be applied to mediation.

I will discuss it with co-authors. Thank you!

Best Regards,
Atsushi KOBAYASHI


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

--------------010106000805020605060804-- From bclaise@cisco.com Wed Jun 17 00:28:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74283A6A2C for ; Wed, 17 Jun 2009 00:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyFJB43VQAzG for ; Wed, 17 Jun 2009 00:28:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 2180E3A6816 for ; Wed, 17 Jun 2009 00:28:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H7SXNK006758; Wed, 17 Jun 2009 09:28:33 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H7SWnx001465; Wed, 17 Jun 2009 09:28:32 +0200 (CEST) Message-ID: <4A389B20.6090308@cisco.com> Date: Wed, 17 Jun 2009 09:28:32 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> In-Reply-To: <4A1BE50E.6040407@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------060100070104070709070608" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:28:24 -0000 This is a multi-part message in MIME format. --------------060100070104070709070608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, Thanks for your review. It's true we spent quite some time on the terminology. This is key for any other mediation function related drafts that will follow > Dear Atsushi, all, > > Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03 > > I think the purpose of the document is much clearer now. > > Apart from the terminology and the introduction, which should be > rewritten, the document is in a good shape. > > In my opinion, the terminology related to Mediation must be rethought > another time before publishing this problem statement as an RFC. > The current terminology section defines the following terms: > > *IPFIX Mediation* > = a function > > *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* > = specific types of IPFIX Mediation > > *IPFIX Mediator* > = devices that implements IPFIX Mediation > > This terminology has several flaws: > - On the one hand, you have troubles to distinguish between IPFIX > Mediation implemented at an "Original Exporter" and IPFIX Mediation > implemented at a "separate IPFIX Mediator/Concentrator/...". > The biggest trouble is the distinction between the intermediate IPFIX Mediator and the top IPFIX Mediator. See my point below. > - On the other hand, the terms do not fit into the current terminology > scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we > talk about the instantiation of a specific function. > See below. > - Finally, the definition of IPFIX Concentrator does not correspond to > the usage of this term in RFC3917. There, a Concentrator is a device, > not a function. > It's true that concentrator in RFC3917 might be perceived as a specific device, even if it's not formally expressed in the RFC. For example, there is no Concentrator definition. However I don't think that the compliance with RFC 3917 is our highest priority ;-). > I like the approach that has been chosen by PSAMP. There, we distinguish > between "Selectors" (which are abstract selection functions) and > "Selection Processes" (which are instantiations of Selectors). Selection > Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest > to apply this approach to Mediation as well. > > In the case of Mediation, we would have abstract Mediation Functions > (anonymization, aggregation, sampling, proxy, distribution). These would > be instantiated in a Mediation Process. A Mediation Process can then be > part of an Exporter (Original Exporter), Collector, or Mediator. > This is where we're going, if you look at figure B of http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 IPFIX (Flow Records / Packet Reports) ^ ^ | +------------------------|-|---------------------+ | IPFIX Mediator | | | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Exporting Process(es) |' | | '----------------------^--------------------' | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Intermediate Process(es) (optional) |' | | '----------------------^--------------------' | | | | | | .---------------------|-+-------------------. | | .----------------------+--------------------.| | | | Collecting Process(es) |' | | '----------------------^--------------------' | +------------------------|-|---------------------+ | IPFIX (Flow Records / Packet Reports) So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set. 5.3.1 . Selection Function . . . . . . . . . . . . . . . . . . 10 5.3.2 . Aggregation Function . . . . . . . . . . . . . . . . . 12 5.3.3 . Correlation Function . . . . . . . . . . . . . . . . . 13 5.3.4 . Modification Function . . . . . . . . . . . . . . . . 14 ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc... The question is: should describe the processes in the problem statement draft? We've been going back and forth. I think it makes more sense in the framework draft. This would be in line between the RFC3917 and the IPFIX architecture RFC5470. Coming back to your questions: - On the one hand, you have troubles to distinguish between IPFIX Mediation implemented at an "Original Exporter" and IPFIX Mediation implemented at a "separate IPFIX Mediator/Concentrator/...". This is what we showed in the figures B and C of the framework draft - On the other hand, the terms do not fit into the current terminology scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we talk about the instantiation of a specific function. I think it will with the framework draft. Does it make sense? Regards, Benoit. --------------060100070104070709070608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard,

Thanks for your review.
It's true we spent quite some time on the terminology. This is key for any other mediation function related drafts that will follow
Dear Atsushi, all,

Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03

I think the purpose of the document is much clearer now.

Apart from the terminology and the introduction, which should be
rewritten, the document is in a good shape.

In my opinion, the terminology related to Mediation must be rethought
another time before publishing this problem statement as an RFC.
The current terminology section defines the following terms:

*IPFIX Mediation*
= a function

*IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
= specific types of IPFIX Mediation

*IPFIX Mediator*
= devices that implements IPFIX Mediation

This terminology has several flaws:
- On the one hand, you have troubles to distinguish between IPFIX
Mediation implemented at an "Original Exporter" and IPFIX Mediation
implemented at a "separate IPFIX Mediator/Concentrator/...".
The biggest trouble is the distinction between the intermediate IPFIX Mediator and the top IPFIX Mediator. See my point below.
- On the other hand, the terms do not fit into the current terminology
scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
talk about the instantiation of a specific function.
See below.
- Finally, the definition of IPFIX Concentrator does not correspond to
the usage of this term in RFC3917. There, a Concentrator is a device,
not a function.
It's true that concentrator in RFC3917 might be perceived as a specific device, even if it's not formally expressed in the RFC. For example, there is no Concentrator definition. However I don't think that the compliance with RFC 3917 is our highest priority ;-). 

I like the approach that has been chosen by PSAMP. There, we distinguish
between "Selectors" (which are abstract selection functions) and
"Selection Processes" (which are instantiations of Selectors). Selection
Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest
to apply this approach to Mediation as well.

In the case of Mediation, we would have abstract Mediation Functions
(anonymization, aggregation, sampling, proxy, distribution). These would
be instantiated in a Mediation Process. A Mediation Process can then be
part of an Exporter (Original Exporter), Collector, or Mediator.
This is where we're going, if you look at figure B of http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02
            IPFIX (Flow Records / Packet Reports)
                              ^
                            ^ |
   +------------------------|-|---------------------+
   | IPFIX Mediator         | |                     |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Exporting Process(es)            |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |    Intermediate Process(es) (optional)    |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Collecting Process(es)           |' |
   | '----------------------^--------------------'  |
   +------------------------|-|---------------------+
                            |
            IPFIX (Flow Records / Packet Reports)

So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set.
       5.3.1.  Selection Function . . . . . . . . . . . . . . . . . . 10
       5.3.2.  Aggregation Function . . . . . . . . . . . . . . . . . 12
       5.3.3.  Correlation Function . . . . . . . . . . . . . . . . . 13
       5.3.4.  Modification Function  . . . . . . . . . . . . . . . . 14
... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc...
The question is: should describe the processes in the problem statement draft? We've been going back and forth. I think it makes more sense in the framework draft. This would be in line between the RFC3917 and the IPFIX architecture RFC5470.

Coming back to your questions:
- On the one hand, you have troubles to distinguish between IPFIX
Mediation implemented at an "Original Exporter" and IPFIX Mediation
implemented at a "separate IPFIX Mediator/Concentrator/...".
This is what we showed in the figures B and C of the framework draft
- On the other hand, the terms do not fit into the current terminology
scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
talk about the instantiation of a specific function.
I think it will with the framework draft.

Does it make sense?

Regards, Benoit.

--------------060100070104070709070608-- From muenz@net.in.tum.de Wed Jun 17 00:59:29 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD053A6BCC for ; Wed, 17 Jun 2009 00:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.271, 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 RH7doZF2bldT for ; Wed, 17 Jun 2009 00:59:28 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 396893A6944 for ; Wed, 17 Jun 2009 00:59:28 -0700 (PDT) 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 E555547D26; Wed, 17 Jun 2009 09:59:37 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id D076C52D2; Wed, 17 Jun 2009 09:59:37 +0200 (CEST) Message-ID: <4A38A2BF.40000@net.in.tum.de> Date: Wed, 17 Jun 2009 10:01:03 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> In-Reply-To: <4A389B20.6090308@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090204060402010604000004" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:59:29 -0000 This is a cryptographically signed message in MIME format. --------------ms090204060402010604000004 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, I agree, Intermediate Processes do not have to be introduced in the problem statement. Atsushi proposed to the following change (see mailing list): >> *IPFIX Mediation* >> =3D a function >> >> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >> =3D specific types of IPFIX Mediation =3D> specific type of IPFIX Mediator (i.e., this is a device, not a funct= ion) This does not yet solve the complicated language w/r to separate/original exporter, but is inline with RFC3917. >> *IPFIX Mediator* >> =3D devices that implements IPFIX Mediation I think this is a good plan. Any objections from your side? Regards, Gerhard Benoit Claise wrote: > Gerhard, >=20 > Thanks for your review. > It's true we spent quite some time on the terminology. This is key for > any other mediation function related drafts that will follow >> Dear Atsushi, all, >> >> Find below my comments for draft-ietf-ipfix-mediators-problem-statemen= t-03 >> >> I think the purpose of the document is much clearer now. >> >> Apart from the terminology and the introduction, which should be >> rewritten, the document is in a good shape. >> >> In my opinion, the terminology related to Mediation must be rethought >> another time before publishing this problem statement as an RFC. >> The current terminology section defines the following terms: >> >> *IPFIX Mediation* >> =3D a function >> >> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >> =3D specific types of IPFIX Mediation >> >> *IPFIX Mediator* >> =3D devices that implements IPFIX Mediation >> >> This terminology has several flaws: >> - On the one hand, you have troubles to distinguish between IPFIX >> Mediation implemented at an "Original Exporter" and IPFIX Mediation >> implemented at a "separate IPFIX Mediator/Concentrator/...". >> =20 > The biggest trouble is the distinction between the intermediate IPFIX > Mediator and the top IPFIX Mediator. See my point below. >> - On the other hand, the terms do not fit into the current terminology= >> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >> talk about the instantiation of a specific function. >> =20 > See below. >> - Finally, the definition of IPFIX Concentrator does not correspond to= >> the usage of this term in RFC3917. There, a Concentrator is a device, >> not a function. >> =20 > It's true that concentrator in RFC3917 might be perceived as a specific= > device, even if it's not formally expressed in the RFC. For example, > there is no Concentrator definition. However I don't think that the > compliance with RFC 3917 is our highest priority ;-). >=20 >> I like the approach that has been chosen by PSAMP. There, we distingui= sh >> between "Selectors" (which are abstract selection functions) and >> "Selection Processes" (which are instantiations of Selectors). Selecti= on >> Processes are finally part of Devices (i.e., PSAMP Exporters). I sugge= st >> to apply this approach to Mediation as well. >> >> In the case of Mediation, we would have abstract Mediation Functions >> (anonymization, aggregation, sampling, proxy, distribution). These wou= ld >> be instantiated in a Mediation Process. A Mediation Process can then b= e >> part of an Exporter (Original Exporter), Collector, or Mediator. >> =20 > This is where we're going, if you look at figure B of > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >=20 > IPFIX (Flow Records / Packet Reports) > ^ > ^ | > +------------------------|-|---------------------+ > | IPFIX Mediator | | | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Exporting Process(es) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Intermediate Process(es) (optional) |' | > | '----------------------^--------------------' | > | | | | > | .---------------------|-+-------------------. | > | .----------------------+--------------------.| | > | | Collecting Process(es) |' | > | '----------------------^--------------------' | > +------------------------|-|---------------------+ > | > IPFIX (Flow Records / Packet Reports) >=20 > So the intermediate process hosts one of several functions defined belo= w or a combination of them, in any sequence or in any set. > 5.3.1 . Selection Function . . . . . . . . . . . . . .= . . . . 10 > 5.3.2 . Aggregation Function . . . . . . . . . . . . .= . . . . 12 > 5.3.3 . Correlation Function . . . . . . . . . . . . .= . . . . 13 > 5.3.4 . Modification Function . . . . . . . . . . . .= . . . . 14 > ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distri= butor, etc... > =20 >=20 > The question is: should describe the processes in the problem statement= > draft? We've been going back and forth. I think it makes more sense in > the framework draft. This would be in line between the RFC3917 and the > IPFIX architecture RFC5470. >=20 > Coming back to your questions: >=20 > - On the one hand, you have troubles to distinguish between IPFIX > Mediation implemented at an "Original Exporter" and IPFIX Mediation= > implemented at a "separate IPFIX Mediator/Concentrator/...". >=20 > This is what we showed in the figures B and C of the framework draft >=20 >=20 > - On the other hand, the terms do not fit into the current terminol= ogy > scheme of IPFIX and PSAMP, where we are used to "XXX Process" when = we > talk about the instantiation of a specific function. >=20 > I think it will with the framework draft. >=20 > Does it make sense? >=20 > Regards, Benoit. >=20 >=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 --------------ms090204060402010604000004 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE3MDgwMTAzWjAjBgkqhkiG9w0BCQQxFgQU SXzzC/46G8B4g0lX0IFoD5YCo3kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAAJORLFS20nwmVLmwjAgCuCeeJ5x+WNamO41CqYYiSU0XRhx Y/R5aBAc8uEbJk1PwgAITywBazWnEAWP+GktXkGX0RTBCu+YX4HWesFVFeISmWUVZBMHvO21 g1ByTtLwWl8kqrFkcKWqyHiwY450M1F2cVp8aaXXbokD+HyQqK7T7z4r74H5PmbVHQjoOE7o eulAUCaSgOiip5hqpRt3pc5Dp9h9khHFD/qJZc0yjvtrcTkxW+voZ8qiPEVdT9/Idrvc60mf A5ODixKWnfqsgHkSeXk/X6eOBpeMZ0kTCmGkccfhtG1Tb/HQj3A1mvZOTDELKwnV6rYEdquB J2tteNgAAAAAAAA= --------------ms090204060402010604000004-- From bclaise@cisco.com Wed Jun 17 01:06:52 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB8D3A6DF5 for ; Wed, 17 Jun 2009 01:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B05CObPHU5hZ for ; Wed, 17 Jun 2009 01:06:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 7C7243A6DF2 for ; Wed, 17 Jun 2009 01:06:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H871u3009811; Wed, 17 Jun 2009 10:07:01 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H86xv8004295; Wed, 17 Jun 2009 10:07:00 +0200 (CEST) Message-ID: <4A38A423.8000804@cisco.com> Date: Wed, 17 Jun 2009 10:06:59 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> In-Reply-To: <20090610211008.6E53.17391CF2@nttv6.net> Content-Type: multipart/alternative; boundary="------------040202010405070407050508" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 08:06:53 -0000 This is a multi-part message in MIME format. --------------040202010405070407050508 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Gerhard and Kobayashi-san, One more email about the terminology as they were more terminology specific comments in the latter part of Gerhard's email. Sorry for the potential confusion > > > > >>> IPFIX Mediation >>> >>> IPFIX Mediation is a generic function that covers the manipulation >>> >> remove "generic" ? >> >> >>> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >>> Messages, or their transmission. The IPFIX Mediation offers one >>> >> Could be read as "covers the transmission of...", which would make an >> Exporting Process a Mediation function. >> >> Also, you sentence does not include "Options Data Records" (I put this >> in quotes because it is not an official term). >> > > Yes, indeed. > >> maybe: >> "...covers the manipulation of the content and transmission of Data >> Records and IPFIX Messages." >> > > Fine. > Actually, I have a problem with this proposal, i.e. adding "transmission" in the IPFIX Mediation definition. It doesn't fit with the following model (coming from the framework draft): +---------------------------+ +---------------------------+ | Collector {l} | | Collector {k} | |[*Application(s)] | |[*Application(s)] | |[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 to Observation Points Where we make a clear distinction between the Intermediate Process and the Exporting Process The question is: can we have a Intermediate Process that is a Mediation Function, for example a IPFIX Concentrator, without exporting? So a Mediation Function does not contain the export. Double checking the terminology, I realize that there is a mistake: OLD: IPFIX Concentrator An IPFIX Concentrator is a type of IPFIX Mediation that receives Flow Records/Packet Reports, correlates them, aggregates them, or modifies them, then exports the new Data Records. NEW: IPFIX Concentrator An IPFIX Concentrator is a type of IPFIX Mediation that receives Flow Records/Packet Reports, correlates them, aggregates them, or modifies them _into new_ Data Records. >>> or multiple of the following capabilities: >>> >>> * content mediation that changes Flow Records/Packet Reports >>> information >>> >>> + aggregating Flow Records/Packet Reports based on a new set >>> of Flow Key fields >>> >>> + correlating a set of Flow Records/Packet Reports >>> >>> + filtering and selecting Flow Records/Packet Reports >>> >>> + modifying Flow Records/Packet Reports, including: >>> >>> - changing the value of specified Information Elements >>> >>> - adding new Information Elements by deriving further Flow >>> or packet properties from existing fields (for example: >>> calculating new metrics or new counters) >>> >>> - deleting specified Information Elements >>> >> in the whole definition: >> s/Flow Records\/Packet Reports/Data Records >> Then how do you stress that the the input can come from both IPFIX and PSAMP? Regards, Benoit. --------------040202010405070407050508 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Gerhard and Kobayashi-san,

One more email about the terminology as they were more terminology specific comments in the latter part of Gerhard's email. Sorry for the potential confusion



  
   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      
remove "generic" ?

    
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.  The IPFIX Mediation offers one
      
Could be read as "covers the transmission of...", which would make an
Exporting Process a Mediation function.

Also, you sentence does not include "Options Data Records" (I put this
in quotes because it is not an official term).
    

Yes, indeed.
  
maybe:
"...covers the manipulation of the content and transmission of Data
Records and IPFIX Messages."
    

Fine.
Actually, I have a problem with this proposal, i.e. adding "transmission" in the IPFIX Mediation definition.
It doesn't fit with the following model (coming from the framework draft):
   +---------------------------+    +---------------------------+
   | Collector {l}             |    | Collector {k}             |
   |[*Application(s)]          |    |[*Application(s)]          |
   |[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 to Observation Points
Where we make a clear distinction between the Intermediate Process and the Exporting Process
The question is: can we have a Intermediate Process that is a Mediation Function, for example a IPFIX Concentrator, without exporting?
So a Mediation Function does not contain the export.

Double checking the terminology, I realize that there is a mistake:
OLD:
   IPFIX Concentrator

      An IPFIX Concentrator is a type of IPFIX Mediation that receives
      Flow Records/Packet Reports, correlates them, aggregates them, or
      modifies them, then exports the new Data Records.

NEW:
   IPFIX Concentrator

      An IPFIX Concentrator is a type of IPFIX Mediation that receives
      Flow Records/Packet Reports, correlates them, aggregates them, or
      modifies them into new Data Records.



      or multiple of the following capabilities:

      *  content mediation that changes Flow Records/Packet Reports
         information

         +  aggregating Flow Records/Packet Reports based on a new set
            of Flow Key fields

         +  correlating a set of Flow Records/Packet Reports

         +  filtering and selecting Flow Records/Packet Reports

         +  modifying Flow Records/Packet Reports, including:

            -  changing the value of specified Information Elements

            -  adding new Information Elements by deriving further Flow
               or packet properties from existing fields (for example:
               calculating new metrics or new counters)

            -  deleting specified Information Elements
      
in the whole definition:
s/Flow Records\/Packet Reports/Data Records
Then how do you stress that the the input can come from both IPFIX and PSAMP?


Regards, Benoit.
--------------040202010405070407050508-- From trammell@tik.ee.ethz.ch Wed Jun 17 02:16:23 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F5528C19E for ; Wed, 17 Jun 2009 02:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pptVl-gXhvPZ for ; Wed, 17 Jun 2009 02:16:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 3AADD28C19D for ; Wed, 17 Jun 2009 02:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id CC7A9D9384; Wed, 17 Jun 2009 11:16:30 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G+yLGCvtsA-Y; Wed, 17 Jun 2009 11:16:30 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7FC81D9330; Wed, 17 Jun 2009 11:16:30 +0200 (MEST) Message-Id: <4483866D-79AC-4094-A7EF-F274CDB1A441@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4A38A2BF.40000@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 11:16:30 +0200 References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:16:23 -0000 'morning Gerhard, Benoit, all, I'm still in the middle of my review (there's a much larger message in =20= my drafts folder, which I'm changing as this discussion develops) but =20= wanted to jump in on this one quickly, inline below... On Jun 17, 2009, at 10:01 AM, Gerhard Muenz wrote: > > Benoit, > > I agree, Intermediate Processes do not have to be introduced in the > problem statement. > > Atsushi proposed to the following change (see mailing list): > >>> *IPFIX Mediation* >>> =3D a function >>> >>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>> =3D specific types of IPFIX Mediation > > =3D> specific type of IPFIX Mediator (i.e., this is a device, not a =20= > function) > > This does not yet solve the complicated language w/r to > separate/original exporter, but is inline with RFC3917. It also doesn't fix a problem in the Implementation Analysis =20 subsections, that suggest the solutions to problems by applying =20 various IPFIX Mediator devices. The suggestion here seems to be that =20 it is the _devices_ that are important (use a concentrator, use a =20 proxy), not the _functions_. This seems wrong, _especially_ at the =20 level at which the problem statement should be. It's the functions =20 that are important here. HOW to execute them is a detail for the =20 framework and drafts below it. (e.g., the early binding to devices seems to imply that if I want to, =20= say, accept both V9 and IPFIX data and forward summary aggregation =20 data to a downstream collector, I need to rack three boxes at the =20 mediation point according to the problem statement. This seems... =20 inappropriately detailed, and incorrect.) This implies we should also step back and re-examine the boundary =20 between the problem statement and framework, and move the appropriate =20= terminology and explanation to the appropriate place. >>> *IPFIX Mediator* >>> =3D devices that implements IPFIX Mediation > > I think this is a good plan. As do I, subject to the consideration above. :) More below, as well... > Any objections from your side? > > Regards, > Gerhard > > > Benoit Claise wrote: >> Gerhard, >> >> Thanks for your review. >> It's true we spent quite some time on the terminology. This is key =20= >> for >> any other mediation function related drafts that will follow >>> Dear Atsushi, all, >>> >>> Find below my comments for draft-ietf-ipfix-mediators-problem-=20 >>> statement-03 >>> >>> I think the purpose of the document is much clearer now. >>> >>> Apart from the terminology and the introduction, which should be >>> rewritten, the document is in a good shape. >>> >>> In my opinion, the terminology related to Mediation must be =20 >>> rethought >>> another time before publishing this problem statement as an RFC. >>> The current terminology section defines the following terms: >>> >>> *IPFIX Mediation* >>> =3D a function >>> >>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>> =3D specific types of IPFIX Mediation >>> >>> *IPFIX Mediator* >>> =3D devices that implements IPFIX Mediation >>> >>> This terminology has several flaws: >>> - On the one hand, you have troubles to distinguish between IPFIX >>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>> >> The biggest trouble is the distinction between the intermediate IPFIX >> Mediator and the top IPFIX Mediator. See my point below. >>> - On the other hand, the terms do not fit into the current =20 >>> terminology >>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when =20= >>> we >>> talk about the instantiation of a specific function. >>> >> See below. >>> - Finally, the definition of IPFIX Concentrator does not =20 >>> correspond to >>> the usage of this term in RFC3917. There, a Concentrator is a =20 >>> device, >>> not a function. >>> >> It's true that concentrator in RFC3917 might be perceived as a =20 >> specific >> device, even if it's not formally expressed in the RFC. For example, >> there is no Concentrator definition. However I don't think that the >> compliance with RFC 3917 is our highest priority ;-). >> >>> I like the approach that has been chosen by PSAMP. There, we =20 >>> distinguish >>> between "Selectors" (which are abstract selection functions) and >>> "Selection Processes" (which are instantiations of Selectors). =20 >>> Selection >>> Processes are finally part of Devices (i.e., PSAMP Exporters). I =20 >>> suggest >>> to apply this approach to Mediation as well. >>> >>> In the case of Mediation, we would have abstract Mediation Functions >>> (anonymization, aggregation, sampling, proxy, distribution). These =20= >>> would >>> be instantiated in a Mediation Process. A Mediation Process can =20 >>> then be >>> part of an Exporter (Original Exporter), Collector, or Mediator. >>> >> This is where we're going, if you look at figure B of >> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >> >> IPFIX (Flow Records / Packet Reports) >> ^ >> ^ | >> +------------------------|-|---------------------+ >> | IPFIX Mediator | | | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Exporting Process(es) |' | >> | '----------------------^--------------------' | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Intermediate Process(es) (optional) |' | >> | '----------------------^--------------------' | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Collecting Process(es) |' | >> | '----------------------^--------------------' | >> +------------------------|-|---------------------+ >> | >> IPFIX (Flow Records / Packet Reports) >> >> So the intermediate process hosts one of several functions defined =20= >> below or a combination of them, in any sequence or in any set. = > > >> 5.3.1 = > >. Selection Function . . . . . . . . . . . . . . . . . . 10 = > > >> 5.3.2 = > >. Aggregation Function . . . . . . . . . . . . . . . . . 12 = > > >> 5.3.3 = > >. Correlation Function . . . . . . . . . . . . . . . . . 13 = > > >> 5.3.4 = > >. Modification Function . . . . . . . . . . . . . . . . 14 = > > >> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX =20 >> Distributor, etc... >> >> >> The question is: should describe the processes in the problem =20 >> statement >> draft? We've been going back and forth. I think it makes more sense =20= >> in >> the framework draft. This would be in line between the RFC3917 and =20= >> the >> IPFIX architecture RFC5470. I would tend to think they go in the framework draft, as well; but =20 then the problem statement should really be limited to talking about =20 the _types of functions_ (without Capital Letter Terminology) that are =20= required to meet the challenges posed by each specific situation. But =20= then, any discussion of devices should be generalized, and moved to =20 the Framework as well. >> Coming back to your questions: >> >> - On the one hand, you have troubles to distinguish between IPFIX >> Mediation implemented at an "Original Exporter" and IPFIX =20 >> Mediation >> implemented at a "separate IPFIX Mediator/Concentrator/...". >> >> This is what we showed in the figures B and C of the framework draft >> >> >> - On the other hand, the terms do not fit into the current =20 >> terminology >> scheme of IPFIX and PSAMP, where we are used to "XXX Process" =20 >> when we >> talk about the instantiation of a specific function. >> >> I think it will with the framework draft. >> >> Does it make sense? Yes. Subject to either of the following arrangements: 1. there is only one type of Intermediate Process, which can host any =20= number of Mediation Functions (this makes the most sense from the =20 implementation point of view), or 2. there exists a type of Intermediate Process for each basic function =20= (an Intermediate Aggregation Process, an Intermediate Selection =20 Process, and so on; this makes the most sense from a formalization =20 point of view)... >> Regards, Benoit. >> >> > > --=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 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Wed Jun 17 02:37:01 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A0FE28C21B for ; Wed, 17 Jun 2009 02:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzagLcok9Yk8 for ; Wed, 17 Jun 2009 02:36:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 147AE28C206 for ; Wed, 17 Jun 2009 02:36:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H9asuK017102; Wed, 17 Jun 2009 11:36:54 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H9arK8016246; Wed, 17 Jun 2009 11:36:53 +0200 (CEST) Message-ID: <4A38B935.6000209@cisco.com> Date: Wed, 17 Jun 2009 11:36:53 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> In-Reply-To: <4A38A2BF.40000@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------010909030000070807060701" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:37:01 -0000 This is a multi-part message in MIME format. --------------010909030000070807060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > Benoit, > > I agree, Intermediate Processes do not have to be introduced in the > problem statement. > > Atsushi proposed to the following change (see mailing list): > > >>> *IPFIX Mediation* >>> = a function >>> >>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>> = specific types of IPFIX Mediation >>> > > => specific type of IPFIX Mediator (i.e., this is a device, not a function) > > This does not yet solve the complicated language w/r to > separate/original exporter, but is inline with RFC3917. > > >>> *IPFIX Mediator* >>> = devices that implements IPFIX Mediation >>> > > I think this is a good plan. > > Any objections from your side? > During the review of the draft version 2 , I went through the full list of ... 5. Mediation Applicability Examples . . . . . . . . . . . . . . . 12 5.1. Adjusting Flow Granularity . . . . . . . . . . . . . . . . 12 5.2. Hierarchical Collecting Infrastructure . . . . . . . . . . 12 5.3. Correlation for Data Records . . . . . . . . . . . . . . . 13 5.4. Time Composition . . . . . . . . . . . . . . . . . . . . . 13 5.5. Spatial Composition . . . . . . . . . . . . . . . . . . . 14 5.6. Data Record Anonymization . . . . . . . . . . . . . . . . 15 5.7. Data Retention . . . . . . . . . . . . . . . . . . . . . . 15 5.8. IPFIX Export from a Branch Office . . . . . . . . . . . . 16 5.9. Distributing Data Records . . . . . . . . . . . . . . . . 17 5.10. Flow-based Sampling and Selection . . . . . . . . . . . . 18 5.11. Interoperability between Legacy Protocols and IPFIX . . . 19 ... trying to see if we have a good mediation terminology for each case. Now, here is the question. All the examples should be categorized by a mediation function or a mediation device? "device" could potentially work, because, in a requirement draft, we don't care (yet) about the framework. Now, if you say: IPFIX Proxy An IPFIX Proxy is a type of IPFIX Mediator that relays incoming ^^^^^^^^ Transport Sessions to one or multiple Collectors. What if I have a mediator that is composed of both the IPFIX Proxy and Concentrator functions? How do you call that beast? Same question if a IPFIX Device such as a router is also an IPFIX Masquerading Proxy: is it first a IPFIX Device, or a IPFIX Masquerading Proxy? I think that using "device" is more restricting than a function when we think about the framework, because we don't know in advance where the function(s) will be applied: in a router, in connection with other functions, etc... Using "device" implies an implicit assumption that, when using a IPFIX Proxy, IPFIX Concentrator, etc. we have different independent boxes. So, isn't it better to say: IPFIX Mediator An IPFIX Mediator is an _IPFIX Device_ that implements one or more IPFIX Mediation capabilities. Examples are devices such as routers, switches, network management systems (NMS), etc. Where: 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. So IPFIX Mediator = devices that implements one or more functions called IPFIX Mediation. Note that I understand your point: "a IPFIX Mediator containing a IPFIX Proxy (function)" doesn't sound intuitive in a sentence... Regards, Benoit > Regards, > Gerhard > > > Benoit Claise wrote: > >> Gerhard, >> >> Thanks for your review. >> It's true we spent quite some time on the terminology. This is key for >> any other mediation function related drafts that will follow >> >>> Dear Atsushi, all, >>> >>> Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03 >>> >>> I think the purpose of the document is much clearer now. >>> >>> Apart from the terminology and the introduction, which should be >>> rewritten, the document is in a good shape. >>> >>> In my opinion, the terminology related to Mediation must be rethought >>> another time before publishing this problem statement as an RFC. >>> The current terminology section defines the following terms: >>> >>> *IPFIX Mediation* >>> = a function >>> >>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>> = specific types of IPFIX Mediation >>> >>> *IPFIX Mediator* >>> = devices that implements IPFIX Mediation >>> >>> This terminology has several flaws: >>> - On the one hand, you have troubles to distinguish between IPFIX >>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>> >>> >> The biggest trouble is the distinction between the intermediate IPFIX >> Mediator and the top IPFIX Mediator. See my point below. >> >>> - On the other hand, the terms do not fit into the current terminology >>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >>> talk about the instantiation of a specific function. >>> >>> >> See below. >> >>> - Finally, the definition of IPFIX Concentrator does not correspond to >>> the usage of this term in RFC3917. There, a Concentrator is a device, >>> not a function. >>> >>> >> It's true that concentrator in RFC3917 might be perceived as a specific >> device, even if it's not formally expressed in the RFC. For example, >> there is no Concentrator definition. However I don't think that the >> compliance with RFC 3917 is our highest priority ;-). >> >> >>> I like the approach that has been chosen by PSAMP. There, we distinguish >>> between "Selectors" (which are abstract selection functions) and >>> "Selection Processes" (which are instantiations of Selectors). Selection >>> Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest >>> to apply this approach to Mediation as well. >>> >>> In the case of Mediation, we would have abstract Mediation Functions >>> (anonymization, aggregation, sampling, proxy, distribution). These would >>> be instantiated in a Mediation Process. A Mediation Process can then be >>> part of an Exporter (Original Exporter), Collector, or Mediator. >>> >>> >> This is where we're going, if you look at figure B of >> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >> >> IPFIX (Flow Records / Packet Reports) >> ^ >> ^ | >> +------------------------|-|---------------------+ >> | IPFIX Mediator | | | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Exporting Process(es) |' | >> | '----------------------^--------------------' | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Intermediate Process(es) (optional) |' | >> | '----------------------^--------------------' | >> | | | | >> | .---------------------|-+-------------------. | >> | .----------------------+--------------------.| | >> | | Collecting Process(es) |' | >> | '----------------------^--------------------' | >> +------------------------|-|---------------------+ >> | >> IPFIX (Flow Records / Packet Reports) >> >> So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set. >> 5.3.1 . Selection Function . . . . . . . . . . . . . . . . . . 10 >> 5.3.2 . Aggregation Function . . . . . . . . . . . . . . . . . 12 >> 5.3.3 . Correlation Function . . . . . . . . . . . . . . . . . 13 >> 5.3.4 . Modification Function . . . . . . . . . . . . . . . . 14 >> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc... >> >> >> The question is: should describe the processes in the problem statement >> draft? We've been going back and forth. I think it makes more sense in >> the framework draft. This would be in line between the RFC3917 and the >> IPFIX architecture RFC5470. >> >> Coming back to your questions: >> >> - On the one hand, you have troubles to distinguish between IPFIX >> Mediation implemented at an "Original Exporter" and IPFIX Mediation >> implemented at a "separate IPFIX Mediator/Concentrator/...". >> >> This is what we showed in the figures B and C of the framework draft >> >> >> - On the other hand, the terms do not fit into the current terminology >> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >> talk about the instantiation of a specific function. >> >> I think it will with the framework draft. >> >> Does it make sense? >> >> Regards, Benoit. >> >> >> > > --------------010909030000070807060701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
Benoit,

I agree, Intermediate Processes do not have to be introduced in the
problem statement.

Atsushi proposed to the following change (see mailing list):

  
*IPFIX Mediation*
= a function

*IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
= specific types of IPFIX Mediation
      

=> specific type of IPFIX Mediator (i.e., this is a device, not a function)

This does not yet solve the complicated language w/r to
separate/original exporter, but is inline with RFC3917.

  
*IPFIX Mediator*
= devices that implements IPFIX Mediation
      

I think this is a good plan.

Any objections from your side?
During the review of the draft version 2 , I went through the full list of ...
  5.  Mediation Applicability Examples . . . . . . . . . . . . . . . 12
     5.1.  Adjusting Flow Granularity . . . . . . . . . . . . . . . . 12
     5.2.  Hierarchical Collecting Infrastructure . . . . . . . . . . 12
     5.3.  Correlation for Data Records . . . . . . . . . . . . . . . 13
     5.4.  Time Composition . . . . . . . . . . . . . . . . . . . . . 13
     5.5.  Spatial Composition  . . . . . . . . . . . . . . . . . . . 14
     5.6.  Data Record Anonymization  . . . . . . . . . . . . . . . . 15
     5.7.  Data Retention . . . . . . . . . . . . . . . . . . . . . . 15
     5.8.  IPFIX Export from a Branch Office  . . . . . . . . . . . . 16
     5.9.  Distributing Data Records  . . . . . . . . . . . . . . . . 17
     5.10. Flow-based Sampling and Selection  . . . . . . . . . . . . 18
     5.11. Interoperability between Legacy Protocols and IPFIX  . . . 19
... trying to see if we have a good mediation terminology for each case.
Now, here is the question. All the examples should be categorized by a mediation function or a mediation device?

 "device" could potentially work, because, in a requirement draft, we don't care (yet) about the framework.
Now, if you say:
   IPFIX Proxy

      An IPFIX Proxy is a type of IPFIX Mediator that relays incoming
                                        ^^^^^^^^ 
      Transport Sessions to one or multiple Collectors.
What if I have a mediator that is composed of both the IPFIX Proxy and Concentrator functions? How do you call that beast?
Same question if a IPFIX Device such as a router is also an IPFIX Masquerading Proxy: is it first a IPFIX Device, or a IPFIX Masquerading Proxy?

I think that using "device" is more restricting than a function when we think about the framework, because we don't know in advance where the function(s) will be applied: in a router, in connection with other functions, etc... Using "device" implies an implicit assumption that, when using a IPFIX Proxy, IPFIX Concentrator, etc. we have different independent boxes.
So, isn't it better to say: 

   IPFIX Mediator

      An IPFIX Mediator is an IPFIX Device that implements one or more
      IPFIX Mediation capabilities.  Examples are devices such as
      routers, switches, network management systems (NMS), etc.
Where:
   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.
So  IPFIX Mediator = devices that implements one or more functions called IPFIX Mediation.

Note that I understand your point: "a IPFIX Mediator containing a IPFIX Proxy (function)" doesn't sound intuitive in a sentence...

Regards, Benoit

Regards,
Gerhard


Benoit Claise wrote:
  
Gerhard,

Thanks for your review.
It's true we spent quite some time on the terminology. This is key for
any other mediation function related drafts that will follow
    
Dear Atsushi, all,

Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03

I think the purpose of the document is much clearer now.

Apart from the terminology and the introduction, which should be
rewritten, the document is in a good shape.

In my opinion, the terminology related to Mediation must be rethought
another time before publishing this problem statement as an RFC.
The current terminology section defines the following terms:

*IPFIX Mediation*
= a function

*IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
= specific types of IPFIX Mediation

*IPFIX Mediator*
= devices that implements IPFIX Mediation

This terminology has several flaws:
- On the one hand, you have troubles to distinguish between IPFIX
Mediation implemented at an "Original Exporter" and IPFIX Mediation
implemented at a "separate IPFIX Mediator/Concentrator/...".
  
      
The biggest trouble is the distinction between the intermediate IPFIX
Mediator and the top IPFIX Mediator. See my point below.
    
- On the other hand, the terms do not fit into the current terminology
scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
talk about the instantiation of a specific function.
  
      
See below.
    
- Finally, the definition of IPFIX Concentrator does not correspond to
the usage of this term in RFC3917. There, a Concentrator is a device,
not a function.
  
      
It's true that concentrator in RFC3917 might be perceived as a specific
device, even if it's not formally expressed in the RFC. For example,
there is no Concentrator definition. However I don't think that the
compliance with RFC 3917 is our highest priority ;-).

    
I like the approach that has been chosen by PSAMP. There, we distinguish
between "Selectors" (which are abstract selection functions) and
"Selection Processes" (which are instantiations of Selectors). Selection
Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest
to apply this approach to Mediation as well.

In the case of Mediation, we would have abstract Mediation Functions
(anonymization, aggregation, sampling, proxy, distribution). These would
be instantiated in a Mediation Process. A Mediation Process can then be
part of an Exporter (Original Exporter), Collector, or Mediator.
  
      
This is where we're going, if you look at figure B of
http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02

            IPFIX (Flow Records / Packet Reports)
                              ^
                            ^ |
   +------------------------|-|---------------------+
   | IPFIX Mediator         | |                     |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Exporting Process(es)            |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |    Intermediate Process(es) (optional)    |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Collecting Process(es)           |' |
   | '----------------------^--------------------'  |
   +------------------------|-|---------------------+
                            |
            IPFIX (Flow Records / Packet Reports)

So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set. <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.1>.  Selection Function . . . . . . . . . . . . . . . . . . 10 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.2>.  Aggregation Function . . . . . . . . . . . . . . . . . 12 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-12>
       5.3.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.3>.  Correlation Function . . . . . . . . . . . . . . . . . 13 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-13>
       5.3.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.4>.  Modification Function  . . . . . . . . . . . . . . . . 14 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-14>
... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc...
  

The question is: should describe the processes in the problem statement
draft? We've been going back and forth. I think it makes more sense in
the framework draft. This would be in line between the RFC3917 and the
IPFIX architecture RFC5470.

Coming back to your questions:

    - On the one hand, you have troubles to distinguish between IPFIX
    Mediation implemented at an "Original Exporter" and IPFIX Mediation
    implemented at a "separate IPFIX Mediator/Concentrator/...".

This is what we showed in the figures B and C of the framework draft


    - On the other hand, the terms do not fit into the current terminology
    scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
    talk about the instantiation of a specific function.

I think it will with the framework draft.

Does it make sense?

Regards, Benoit.

--------------010909030000070807060701-- From bclaise@cisco.com Wed Jun 17 02:49:22 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0343A6809 for ; Wed, 17 Jun 2009 02:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, GB_I_LETTER=-2] 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 qRSYwh52Qmj9 for ; Wed, 17 Jun 2009 02:49:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 78E193A68D5 for ; Wed, 17 Jun 2009 02:49:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H9kt1n017907; Wed, 17 Jun 2009 11:46:55 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5H9ksBV004480; Wed, 17 Jun 2009 11:46:54 +0200 (CEST) Message-ID: <4A38BB8E.7030901@cisco.com> Date: Wed, 17 Jun 2009 11:46:54 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Trammell References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> <4483866D-79AC-4094-A7EF-F274CDB1A441@tik.ee.ethz.ch> In-Reply-To: <4483866D-79AC-4094-A7EF-F274CDB1A441@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:49:22 -0000 Hi Brian, > 'morning Gerhard, Benoit, all, > > I'm still in the middle of my review (there's a much larger message in > my drafts folder, which I'm changing as this discussion develops) but > wanted to jump in on this one quickly, inline below... > > On Jun 17, 2009, at 10:01 AM, Gerhard Muenz wrote: > >> >> Benoit, >> >> I agree, Intermediate Processes do not have to be introduced in the >> problem statement. >> >> Atsushi proposed to the following change (see mailing list): >> >>>> *IPFIX Mediation* >>>> = a function >>>> >>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>> = specific types of IPFIX Mediation >> >> => specific type of IPFIX Mediator (i.e., this is a device, not a >> function) >> >> This does not yet solve the complicated language w/r to >> separate/original exporter, but is inline with RFC3917. > > It also doesn't fix a problem in the Implementation Analysis > subsections, that suggest the solutions to problems by applying > various IPFIX Mediator devices. The suggestion here seems to be that > it is the _devices_ that are important (use a concentrator, use a > proxy), not the _functions_. This seems wrong, _especially_ at the > level at which the problem statement should be. It's the functions > that are important here. HOW to execute them is a detail for the > framework and drafts below it. > > (e.g., the early binding to devices seems to imply that if I want to, > say, accept both V9 and IPFIX data and forward summary aggregation > data to a downstream collector, I need to rack three boxes at the > mediation point according to the problem statement. This seems... > inappropriately detailed, and incorrect.) Exactly, this is the topic of my previous email. > > This implies we should also step back and re-examine the boundary > between the problem statement and framework, and move the appropriate > terminology and explanation to the appropriate place. > >>>> *IPFIX Mediator* >>>> = devices that implements IPFIX Mediation >> >> I think this is a good plan. > > As do I, subject to the consideration above. :) > > More below, as well... > >> Any objections from your side? >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >>> Gerhard, >>> >>> Thanks for your review. >>> It's true we spent quite some time on the terminology. This is key for >>> any other mediation function related drafts that will follow >>>> Dear Atsushi, all, >>>> >>>> Find below my comments for >>>> draft-ietf-ipfix-mediators-problem-statement-03 >>>> >>>> I think the purpose of the document is much clearer now. >>>> >>>> Apart from the terminology and the introduction, which should be >>>> rewritten, the document is in a good shape. >>>> >>>> In my opinion, the terminology related to Mediation must be rethought >>>> another time before publishing this problem statement as an RFC. >>>> The current terminology section defines the following terms: >>>> >>>> *IPFIX Mediation* >>>> = a function >>>> >>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>> = specific types of IPFIX Mediation >>>> >>>> *IPFIX Mediator* >>>> = devices that implements IPFIX Mediation >>>> >>>> This terminology has several flaws: >>>> - On the one hand, you have troubles to distinguish between IPFIX >>>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>> >>> The biggest trouble is the distinction between the intermediate IPFIX >>> Mediator and the top IPFIX Mediator. See my point below. >>>> - On the other hand, the terms do not fit into the current terminology >>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >>>> talk about the instantiation of a specific function. >>>> >>> See below. >>>> - Finally, the definition of IPFIX Concentrator does not correspond to >>>> the usage of this term in RFC3917. There, a Concentrator is a device, >>>> not a function. >>>> >>> It's true that concentrator in RFC3917 might be perceived as a specific >>> device, even if it's not formally expressed in the RFC. For example, >>> there is no Concentrator definition. However I don't think that the >>> compliance with RFC 3917 is our highest priority ;-). >>> >>>> I like the approach that has been chosen by PSAMP. There, we >>>> distinguish >>>> between "Selectors" (which are abstract selection functions) and >>>> "Selection Processes" (which are instantiations of Selectors). >>>> Selection >>>> Processes are finally part of Devices (i.e., PSAMP Exporters). I >>>> suggest >>>> to apply this approach to Mediation as well. >>>> >>>> In the case of Mediation, we would have abstract Mediation Functions >>>> (anonymization, aggregation, sampling, proxy, distribution). These >>>> would >>>> be instantiated in a Mediation Process. A Mediation Process can >>>> then be >>>> part of an Exporter (Original Exporter), Collector, or Mediator. >>>> >>> This is where we're going, if you look at figure B of >>> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >>> >>> IPFIX (Flow Records / Packet Reports) >>> ^ >>> ^ | >>> +------------------------|-|---------------------+ >>> | IPFIX Mediator | | | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Exporting Process(es) |' | >>> | '----------------------^--------------------' | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Intermediate Process(es) (optional) |' | >>> | '----------------------^--------------------' | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Collecting Process(es) |' | >>> | '----------------------^--------------------' | >>> +------------------------|-|---------------------+ >>> | >>> IPFIX (Flow Records / Packet Reports) >>> >>> So the intermediate process hosts one of several functions defined >>> below or a combination of them, in any sequence or in any set. >>> >>> >>> 5.3.1 >>> . >>> Selection Function . . . . . . . . . . . . . . . . . . 10 >>> >>> >>> 5.3.2 >>> . >>> Aggregation Function . . . . . . . . . . . . . . . . . 12 >>> >>> >>> 5.3.3 >>> . >>> Correlation Function . . . . . . . . . . . . . . . . . 13 >>> >>> >>> 5.3.4 >>> . >>> Modification Function . . . . . . . . . . . . . . . . 14 >>> >>> >>> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX >>> Distributor, etc... >>> >>> >>> The question is: should describe the processes in the problem statement >>> draft? We've been going back and forth. I think it makes more sense in >>> the framework draft. This would be in line between the RFC3917 and the >>> IPFIX architecture RFC5470. > > I would tend to think they go in the framework draft, as well; but > then the problem statement should really be limited to talking about > the _types of functions_ (without Capital Letter Terminology) that are > required to meet the challenges posed by each specific situation. But > then, any discussion of devices should be generalized, and moved to > the Framework as well. > >>> Coming back to your questions: >>> >>> - On the one hand, you have troubles to distinguish between IPFIX >>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>> >>> This is what we showed in the figures B and C of the framework draft >>> >>> >>> - On the other hand, the terms do not fit into the current >>> terminology >>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" >>> when we >>> talk about the instantiation of a specific function. >>> >>> I think it will with the framework draft. >>> >>> Does it make sense? > > Yes. Subject to either of the following arrangements: > > 1. there is only one type of Intermediate Process, which can host any > number of Mediation Functions (this makes the most sense from the > implementation point of view), or > > 2. there exists a type of Intermediate Process for each basic function > (an Intermediate Aggregation Process, an Intermediate Selection > Process, and so on; this makes the most sense from a formalization > point of view)... We could go either way, but I guess that the future drafts specifying specific mediation functions would prefer the latter. Regards, Benoit. > >>> Regards, Benoit. >>> >>> >> >> -- >> Dipl.-Ing. Gerhard Münz >> Chair for Network Architectures and Services (I8) >> Department of Informatics >> Technische Universität München >> Boltzmannstr. 3, 85748 Garching bei München, Germany >> Phone: +49 89 289-18008 Fax: +49 89 289-18033 >> E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > From trammell@tik.ee.ethz.ch Wed Jun 17 02:49:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB783A6809 for ; Wed, 17 Jun 2009 02:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 xvwIlsas7kPH for ; Wed, 17 Jun 2009 02:49:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5254128C1D4 for ; Wed, 17 Jun 2009 02:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3C120D9361; Wed, 17 Jun 2009 11:48:47 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KM6pDrCVZGZE; Wed, 17 Jun 2009 11:48:47 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id E21E6D9360; Wed, 17 Jun 2009 11:48:46 +0200 (MEST) Message-Id: From: Brian Trammell To: Benoit Claise In-Reply-To: <4A38B935.6000209@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 11:48:46 +0200 References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> <4A38B935.6000209@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 09:49:27 -0000 hi Benoit, all, (my previous message could have been, in other words, "everything Benoit is about to say..." :) ) short replies inline... On Jun 17, 2009, at 11:36 AM, Benoit Claise wrote: > Gerhard, >> >> Benoit, >> >> I agree, Intermediate Processes do not have to be introduced in the >> problem statement. >> >> Atsushi proposed to the following change (see mailing list): >> >> >>>> *IPFIX Mediation* >>>> = a function >>>> >>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>> = specific types of IPFIX Mediation >>>> >> >> => specific type of IPFIX Mediator (i.e., this is a device, not a >> function) >> >> This does not yet solve the complicated language w/r to >> separate/original exporter, but is inline with RFC3917. >> >> >>>> *IPFIX Mediator* >>>> = devices that implements IPFIX Mediation >>>> >> >> I think this is a good plan. >> >> Any objections from your side? >> > During the review of the draft version 2 , I went through the full > list of ... > 5. Mediation Applicability Examples . . . . . . . . . . . . . . . > 12 > 5.1. Adjusting Flow > Granularity . . . . . . . . . . . . . . . . 12 > 5.2. Hierarchical Collecting > Infrastructure . . . . . . . . . . 12 > 5.3. Correlation for Data > Records . . . . . . . . . . . . . . . 13 > 5.4. Time > Composition . . . . . . . . . . . . . . . . . . . . . 13 > 5.5. Spatial > Composition . . . . . . . . . . . . . . . . . . . 14 > 5.6. Data Record > Anonymization . . . . . . . . . . . . . . . . 15 > 5.7. Data > Retention . . . . . . . . . . . . . . . . . . . . . . 15 > 5.8. IPFIX Export from a Branch > Office . . . . . . . . . . . . 16 > 5.9. Distributing Data > Records . . . . . . . . . . . . . . . . 17 > 5.10. Flow-based Sampling and > Selection . . . . . . . . . . . . 18 > 5.11. Interoperability between Legacy Protocols and > IPFIX . . . 19 > ... trying to see if we have a good mediation terminology for each > case. > Now, here is the question. All the examples should be categorized by > a mediation function or a mediation device? Function. :) > "device" could potentially work, because, in a requirement draft, > we don't care (yet) about the framework. > Now, if you say: > IPFIX Proxy > > An IPFIX Proxy is a type of IPFIX Mediator that relays incoming > ^^^^^^^^ > Transport Sessions to one or multiple Collectors. > What if I have a mediator that is composed of both the IPFIX Proxy > and Concentrator functions? How do you call that beast? > Same question if a IPFIX Device such as a router is also an IPFIX > Masquerading Proxy: is it first a IPFIX Device, or a IPFIX > Masquerading Proxy? > > I think that using "device" is more restricting than a function when > we think about the framework, because we don't know in advance where > the function(s) will be applied: in a router, in connection with > other functions, etc... Using "device" implies an implicit > assumption that, when using a IPFIX Proxy, IPFIX Concentrator, etc. > we have different independent boxes. > So, isn't it better to say: > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. > Where: > 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. > So IPFIX Mediator = devices that implements one or more functions > called IPFIX Mediation. Exactly. And that's exactly the level at which we should be addressing this here, in the problem statement. > Note that I understand your point: "a IPFIX Mediator containing a > IPFIX Proxy (function)" doesn't sound intuitive in a sentence... Why are we even talking about explicit IPFIX Mediator device subclasses here (beyond the fact that we want to point out that mediation is an expansion of the Concentrator defined in 3917)? Can't we just handle this in a "history" or "motivation" subsection of the introduction? "Note that Mediation was considered by... [RFC3917]..." or the like. If we want to introduce that terminology for real, let's put it in the Framework. But I'm still skeptical of restricting the framework to specific types of devices (or, even, specific types of functions) even at the Framework level? Or do we know that we are today smart enough to classify completely every possible thing you can do to a stream of IPFIX records? (If I keep this up I'll have covered my whole review just in replies to this thread. ;) ) Cheers, Brian > Regards, Benoit > >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >> >>> Gerhard, >>> >>> Thanks for your review. >>> It's true we spent quite some time on the terminology. This is key >>> for >>> any other mediation function related drafts that will follow >>> >>>> Dear Atsushi, all, >>>> >>>> Find below my comments for draft-ietf-ipfix-mediators-problem- >>>> statement-03 >>>> >>>> I think the purpose of the document is much clearer now. >>>> >>>> Apart from the terminology and the introduction, which should be >>>> rewritten, the document is in a good shape. >>>> >>>> In my opinion, the terminology related to Mediation must be >>>> rethought >>>> another time before publishing this problem statement as an RFC. >>>> The current terminology section defines the following terms: >>>> >>>> *IPFIX Mediation* >>>> = a function >>>> >>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>> = specific types of IPFIX Mediation >>>> >>>> *IPFIX Mediator* >>>> = devices that implements IPFIX Mediation >>>> >>>> This terminology has several flaws: >>>> - On the one hand, you have troubles to distinguish between IPFIX >>>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>> >>>> >>> The biggest trouble is the distinction between the intermediate >>> IPFIX >>> Mediator and the top IPFIX Mediator. See my point below. >>> >>>> - On the other hand, the terms do not fit into the current >>>> terminology >>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" >>>> when we >>>> talk about the instantiation of a specific function. >>>> >>>> >>> See below. >>> >>>> - Finally, the definition of IPFIX Concentrator does not >>>> correspond to >>>> the usage of this term in RFC3917. There, a Concentrator is a >>>> device, >>>> not a function. >>>> >>>> >>> It's true that concentrator in RFC3917 might be perceived as a >>> specific >>> device, even if it's not formally expressed in the RFC. For example, >>> there is no Concentrator definition. However I don't think that the >>> compliance with RFC 3917 is our highest priority ;-). >>> >>> >>>> I like the approach that has been chosen by PSAMP. There, we >>>> distinguish >>>> between "Selectors" (which are abstract selection functions) and >>>> "Selection Processes" (which are instantiations of Selectors). >>>> Selection >>>> Processes are finally part of Devices (i.e., PSAMP Exporters). I >>>> suggest >>>> to apply this approach to Mediation as well. >>>> >>>> In the case of Mediation, we would have abstract Mediation >>>> Functions >>>> (anonymization, aggregation, sampling, proxy, distribution). >>>> These would >>>> be instantiated in a Mediation Process. A Mediation Process can >>>> then be >>>> part of an Exporter (Original Exporter), Collector, or Mediator. >>>> >>>> >>> This is where we're going, if you look at figure B of >>> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >>> >>> IPFIX (Flow Records / Packet Reports) >>> ^ >>> ^ | >>> +------------------------|-|---------------------+ >>> | IPFIX Mediator | | | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Exporting Process(es) |' | >>> | '----------------------^--------------------' | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Intermediate Process(es) (optional) |' | >>> | '----------------------^--------------------' | >>> | | | | >>> | .---------------------|-+-------------------. | >>> | .----------------------+--------------------.| | >>> | | Collecting Process(es) |' | >>> | '----------------------^--------------------' | >>> +------------------------|-|---------------------+ >>> | >>> IPFIX (Flow Records / Packet Reports) >>> >>> So the intermediate process hosts one of several functions defined >>> below or a combination of them, in any sequence or in any set. >> > >>> 5.3.1 >> >. Selection Function . . . . . . . . . . . . . . . . . . 10 >> > >>> 5.3.2 >> >. Aggregation Function . . . . . . . . . . . . . . . . . 12 >> > >>> 5.3.3 >> >. Correlation Function . . . . . . . . . . . . . . . . . 13 >> > >>> 5.3.4 >> >. Modification Function . . . . . . . . . . . . . . . . 14 >> > >>> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX >>> Distributor, etc... >>> >>> >>> The question is: should describe the processes in the problem >>> statement >>> draft? We've been going back and forth. I think it makes more >>> sense in >>> the framework draft. This would be in line between the RFC3917 and >>> the >>> IPFIX architecture RFC5470. >>> >>> Coming back to your questions: >>> >>> - On the one hand, you have troubles to distinguish between >>> IPFIX >>> Mediation implemented at an "Original Exporter" and IPFIX >>> Mediation >>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>> >>> This is what we showed in the figures B and C of the framework draft >>> >>> >>> - On the other hand, the terms do not fit into the current >>> terminology >>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" >>> when we >>> talk about the instantiation of a specific function. >>> >>> I think it will with the framework draft. >>> >>> Does it make sense? >>> >>> Regards, Benoit. >>> >>> >>> >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Wed Jun 17 03:13:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AFC3A6E23 for ; Wed, 17 Jun 2009 03:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USd7qsrMsimw for ; Wed, 17 Jun 2009 03:13:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 338D33A6968 for ; Wed, 17 Jun 2009 03:13:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5HABlif019834; Wed, 17 Jun 2009 12:11:47 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5HABkOb019958; Wed, 17 Jun 2009 12:11:46 +0200 (CEST) Message-ID: <4A38C162.7000504@cisco.com> Date: Wed, 17 Jun 2009 12:11:46 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Trammell References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> <4A38B935.6000209@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000040905080907070402" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:13:10 -0000 This is a multi-part message in MIME format. --------------050000040905080907070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, > >> Note that I understand your point: "a IPFIX Mediator containing a >> IPFIX Proxy (function)" doesn't sound intuitive in a sentence... > > Why are we even talking about explicit IPFIX Mediator device > subclasses here (beyond the fact that we want to point out that > mediation is an expansion of the Concentrator defined in 3917)? Can't > we just handle this in a "history" or "motivation" subsection of the > introduction? "Note that Mediation was considered by... [RFC3917]..." > or the like. This was our intend behind the sentence: While the IPFIX requirements defined in [RFC3917] mention an intermediate function, such as an IPFIX Proxy or an IPFIX Concentrator, there are no documents defining the function called IPFIX Mediation. Should we change it? > If we want to introduce that terminology for real, let's put it in the > Framework. Since - the terminology must answer all application examples in the problem statement - the terminology is framework dependent we must find the answer now: postponing the discussion won't help. Once we have an agreement, why not put in both drafts > But I'm still skeptical of restricting the framework to specific types > of devices (or, even, specific types of functions) even at the > Framework level? We're not... We have the IPFIX Mediation a generic function, and some more specific functions derived from it. And future drafts can have their own function. For example, a time-based, flow-based, packet-size dependent new function. Actually, re-reading the definition, you're fully right: we are restricting the scope of the Mediation Function OLD: IPFIX Mediation is a generic function that covers the manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages, or their transmission. The IPFIX Mediation offers one or multiple of the following capabilities: NEW: IPFIX Mediation is a generic function that covers the manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages, or their transmission. _Here is a series of IPFIX Mediation examples:_ Regards, Benoit. > Or do we know that we are today smart enough to classify completely > every possible thing you can do to a stream of IPFIX records? > > (If I keep this up I'll have covered my whole review just in replies > to this thread. ;) ) > > Cheers, > > Brian > >> Regards, Benoit >> >>> Regards, >>> Gerhard >>> >>> >>> Benoit Claise wrote: >>> >>>> Gerhard, >>>> >>>> Thanks for your review. >>>> It's true we spent quite some time on the terminology. This is key for >>>> any other mediation function related drafts that will follow >>>> >>>>> Dear Atsushi, all, >>>>> >>>>> Find below my comments for >>>>> draft-ietf-ipfix-mediators-problem-statement-03 >>>>> >>>>> I think the purpose of the document is much clearer now. >>>>> >>>>> Apart from the terminology and the introduction, which should be >>>>> rewritten, the document is in a good shape. >>>>> >>>>> In my opinion, the terminology related to Mediation must be rethought >>>>> another time before publishing this problem statement as an RFC. >>>>> The current terminology section defines the following terms: >>>>> >>>>> *IPFIX Mediation* >>>>> = a function >>>>> >>>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>>> = specific types of IPFIX Mediation >>>>> >>>>> *IPFIX Mediator* >>>>> = devices that implements IPFIX Mediation >>>>> >>>>> This terminology has several flaws: >>>>> - On the one hand, you have troubles to distinguish between IPFIX >>>>> Mediation implemented at an "Original Exporter" and IPFIX Mediation >>>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>>> >>>>> >>>> The biggest trouble is the distinction between the intermediate IPFIX >>>> Mediator and the top IPFIX Mediator. See my point below. >>>> >>>>> - On the other hand, the terms do not fit into the current >>>>> terminology >>>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we >>>>> talk about the instantiation of a specific function. >>>>> >>>>> >>>> See below. >>>> >>>>> - Finally, the definition of IPFIX Concentrator does not >>>>> correspond to >>>>> the usage of this term in RFC3917. There, a Concentrator is a device, >>>>> not a function. >>>>> >>>>> >>>> It's true that concentrator in RFC3917 might be perceived as a >>>> specific >>>> device, even if it's not formally expressed in the RFC. For example, >>>> there is no Concentrator definition. However I don't think that the >>>> compliance with RFC 3917 is our highest priority ;-). >>>> >>>> >>>>> I like the approach that has been chosen by PSAMP. There, we >>>>> distinguish >>>>> between "Selectors" (which are abstract selection functions) and >>>>> "Selection Processes" (which are instantiations of Selectors). >>>>> Selection >>>>> Processes are finally part of Devices (i.e., PSAMP Exporters). I >>>>> suggest >>>>> to apply this approach to Mediation as well. >>>>> >>>>> In the case of Mediation, we would have abstract Mediation Functions >>>>> (anonymization, aggregation, sampling, proxy, distribution). These >>>>> would >>>>> be instantiated in a Mediation Process. A Mediation Process can >>>>> then be >>>>> part of an Exporter (Original Exporter), Collector, or Mediator. >>>>> >>>>> >>>> This is where we're going, if you look at figure B of >>>> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >>>> >>>> IPFIX (Flow Records / Packet Reports) >>>> ^ >>>> ^ | >>>> +------------------------|-|---------------------+ >>>> | IPFIX Mediator | | | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Exporting Process(es) |' | >>>> | '----------------------^--------------------' | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Intermediate Process(es) (optional) |' | >>>> | '----------------------^--------------------' | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Collecting Process(es) |' | >>>> | '----------------------^--------------------' | >>>> +------------------------|-|---------------------+ >>>> | >>>> IPFIX (Flow Records / Packet Reports) >>>> >>>> So the intermediate process hosts one of several functions defined >>>> below or a combination of them, in any sequence or in any set. >>>> >>>> >>>> 5.3.1 >>>> . >>>> Selection Function . . . . . . . . . . . . . . . . . . 10 >>>> >>>> >>>> 5.3.2 >>>> . >>>> Aggregation Function . . . . . . . . . . . . . . . . . 12 >>>> >>>> >>>> 5.3.3 >>>> . >>>> Correlation Function . . . . . . . . . . . . . . . . . 13 >>>> >>>> >>>> 5.3.4 >>>> . >>>> Modification Function . . . . . . . . . . . . . . . . 14 >>>> >>>> >>>> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX >>>> Distributor, etc... >>>> >>>> >>>> The question is: should describe the processes in the problem >>>> statement >>>> draft? We've been going back and forth. I think it makes more sense in >>>> the framework draft. This would be in line between the RFC3917 and the >>>> IPFIX architecture RFC5470. >>>> >>>> Coming back to your questions: >>>> >>>> - On the one hand, you have troubles to distinguish between IPFIX >>>> Mediation implemented at an "Original Exporter" and IPFIX >>>> Mediation >>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>> >>>> This is what we showed in the figures B and C of the framework draft >>>> >>>> >>>> - On the other hand, the terms do not fit into the current >>>> terminology >>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" >>>> when we >>>> talk about the instantiation of a specific function. >>>> >>>> I think it will with the framework draft. >>>> >>>> Does it make sense? >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>> >>> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------050000040905080907070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Note that I understand your point: "a IPFIX Mediator containing a IPFIX Proxy (function)" doesn't sound intuitive in a sentence...

Why are we even talking about explicit IPFIX Mediator device subclasses here (beyond the fact that we want to point out that mediation is an expansion of the Concentrator defined in 3917)? Can't we just handle this in a "history" or "motivation" subsection of the introduction? "Note that Mediation was considered by... [RFC3917]..." or the like.
This was our intend behind the sentence:
   While the IPFIX requirements defined in [RFC3917] mention an
   intermediate function, such as an IPFIX Proxy or an IPFIX
   Concentrator, there are no documents defining the function called
   IPFIX Mediation.
Should we change it?
If we want to introduce that terminology for real, let's put it in the Framework.
Since
    - the terminology must answer all application examples in the problem statement
    - the terminology is framework dependent
we must find the answer now: postponing the discussion won't help.
Once we have an agreement, why not put in both drafts
But I'm still skeptical of restricting the framework to specific types of devices (or, even, specific types of functions) even at the Framework level?
We're not...
We have the IPFIX Mediation a generic function, and some more specific functions derived from it. And future drafts can have their own function. For example, a time-based, flow-based, packet-size dependent new function.

Actually, re-reading the definition, you're fully right: we are restricting the scope of the Mediation Function

OLD:
      IPFIX Mediation is a generic function that covers the manipulation
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.  The IPFIX Mediation offers one
      or multiple of the following capabilities:
NEW:
      IPFIX Mediation is a generic function that covers the manipulation
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.  Here is a series of IPFIX 
      Mediation examples:

Regards, Benoit.
Or do we know that we are today smart enough to classify completely every possible thing you can do to a stream of IPFIX records?

(If I keep this up I'll have covered my whole review just in replies to this thread. ;) )

Cheers,

Brian

Regards, Benoit

Regards,
Gerhard


Benoit Claise wrote:

Gerhard,

Thanks for your review.
It's true we spent quite some time on the terminology. This is key for
any other mediation function related drafts that will follow

Dear Atsushi, all,

Find below my comments for draft-ietf-ipfix-mediators-problem-statement-03

I think the purpose of the document is much clearer now.

Apart from the terminology and the introduction, which should be
rewritten, the document is in a good shape.

In my opinion, the terminology related to Mediation must be rethought
another time before publishing this problem statement as an RFC.
The current terminology section defines the following terms:

*IPFIX Mediation*
= a function

*IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor*
= specific types of IPFIX Mediation

*IPFIX Mediator*
= devices that implements IPFIX Mediation

This terminology has several flaws:
- On the one hand, you have troubles to distinguish between IPFIX
Mediation implemented at an "Original Exporter" and IPFIX Mediation
implemented at a "separate IPFIX Mediator/Concentrator/...".


The biggest trouble is the distinction between the intermediate IPFIX
Mediator and the top IPFIX Mediator. See my point below.

- On the other hand, the terms do not fit into the current terminology
scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
talk about the instantiation of a specific function.


See below.

- Finally, the definition of IPFIX Concentrator does not correspond to
the usage of this term in RFC3917. There, a Concentrator is a device,
not a function.


It's true that concentrator in RFC3917 might be perceived as a specific
device, even if it's not formally expressed in the RFC. For example,
there is no Concentrator definition. However I don't think that the
compliance with RFC 3917 is our highest priority ;-).


I like the approach that has been chosen by PSAMP. There, we distinguish
between "Selectors" (which are abstract selection functions) and
"Selection Processes" (which are instantiations of Selectors). Selection
Processes are finally part of Devices (i.e., PSAMP Exporters). I suggest
to apply this approach to Mediation as well.

In the case of Mediation, we would have abstract Mediation Functions
(anonymization, aggregation, sampling, proxy, distribution). These would
be instantiated in a Mediation Process. A Mediation Process can then be
part of an Exporter (Original Exporter), Collector, or Mediator.


This is where we're going, if you look at figure B of
http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02

            IPFIX (Flow Records / Packet Reports)
                              ^
                            ^ |
   +------------------------|-|---------------------+
   | IPFIX Mediator         | |                     |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Exporting Process(es)            |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |    Intermediate Process(es) (optional)    |' |
   | '----------------------^--------------------'  |
   |                        | |                     |
   |  .---------------------|-+-------------------. |
   | .----------------------+--------------------.| |
   | |          Collecting Process(es)           |' |
   | '----------------------^--------------------'  |
   +------------------------|-|---------------------+
                            |
            IPFIX (Flow Records / Packet Reports)

So the intermediate process hosts one of several functions defined below or a combination of them, in any sequence or in any set. <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.1 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.1>.  Selection Function . . . . . . . . . . . . . . . . . . 10 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-10>
       5.3.2 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.2>.  Aggregation Function . . . . . . . . . . . . . . . . . 12 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-12>
       5.3.3 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.3>.  Correlation Function . . . . . . . . . . . . . . . . . 13 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-13>
       5.3.4 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#section-5.3.4>.  Modification Function  . . . . . . . . . . . . . . . . 14 <http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02#page-14>
... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor, etc...


The question is: should describe the processes in the problem statement
draft? We've been going back and forth. I think it makes more sense in
the framework draft. This would be in line between the RFC3917 and the
IPFIX architecture RFC5470.

Coming back to your questions:

    - On the one hand, you have troubles to distinguish between IPFIX
    Mediation implemented at an "Original Exporter" and IPFIX Mediation
    implemented at a "separate IPFIX Mediator/Concentrator/...".

This is what we showed in the figures B and C of the framework draft


    - On the other hand, the terms do not fit into the current terminology
    scheme of IPFIX and PSAMP, where we are used to "XXX Process" when we
    talk about the instantiation of a specific function.

I think it will with the framework draft.

Does it make sense?

Regards, Benoit.






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

--------------050000040905080907070402-- From dromasca@avaya.com Wed Jun 17 03:24:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10B063A686C for ; Wed, 17 Jun 2009 03:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 kPVw897rW+6n for ; Wed, 17 Jun 2009 03:24:48 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 543B03A6E26 for ; Wed, 17 Jun 2009 03:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,235,1243828800"; d="scan'208";a="164537416" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 17 Jun 2009 06:24:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Jun 2009 06:24:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 12:24:04 +0200 Message-ID: In-Reply-To: <4A3805EC.3010702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity Thread-Index: AcnuxEy748CZTm4LTNiT682ZDhUxoAAb++Hg References: <4A3805EC.3010702@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:24:49 -0000 Hi Benoit, Yes, this is the type of information that I was looking for. My reading of your answer is that the impact of adding SCTP streams in an existing session versus opening a new SCTP session is minor, with a possible plus of efficiency at setup time. Processing overhead and message overhead may potentially be a problem, and care should be exercised in deployment in order to understand the effects.=20 Can we add corresponding text on this?=20 Thanks and Regards, Dan > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Tuesday, June 16, 2009 11:52 PM > To: Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20 > (peterlei); Michael Tuexen > Subject: Re: [IPFIX] AD Review of=20 > draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 > performance and capacity >=20 > Dan, > > Please find below the AD review for > > draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature=20 > > enough to go to IETF Last Call. Unless there are any=20 > special comments=20 > > or concerns I will send it to IETF Last Call by tomorrow. > > > > Please consider the comments below together with the other=20 > IETF Last=20 > > Call comments. The comments are divided into Technical and Editorial > > > > T1. There is not information concerning the impact on=20 > performance and=20 > > capacity of the reporting and collecting processes. Should=20 > we expect=20 > > any considerable impact on performance and/or capacity? If any=20 > > implementation experience is available I would suggest that=20 > we record=20 > > it. > > =20 > Collecting information from the authors of=20 > draft-stewart-tsvwg-sctpstrrst and=20 > draft-ietf-ipfix-export-per-sctp-stream-02, here are the conclusions: > * We were not too sure what is meant by "performance and=20 > capacity" in this context. > * If the question is about: What's the impact of additional=20 > SCTP streams in an existing session versus opening a new SCTP=20 > session? The impact is > minor: > - You have of course a message exchange to add the streams. > - You end up adding 16-24 bytes per stream. > - It is more lightweight to set up additional streams=20 > compared to setting up a new association. > The only thing that comes into my mind is throughput which > * If the question is about the throughput that could be=20 > impaired by processing overhead and message overhead. > - With respect of processing overhead, I have no idea how the=20 > utilization of a large number of streams influences the=20 > performance of the SCTP socket. I could imagine that a lot of=20 > state information must be stored. > - With respect of message overhead, we can say that the fact=20 > that we discourage multiplexing templates and data records of=20 > different template ids may lead to a larger message overhead.=20 > If the data record rate is low for a specific template, the=20 > exporting process might not be able to optimally fill the=20 > IPFIX messages. Hence, we have more overhead due to=20 > additional IPFIX message headers and SCTP chunk headers. >=20 > Is this what you have in mind? >=20 > Regards, Benoit. >=20 >=20 From j.schoenwaelder@jacobs-university.de Wed Jun 17 04:07:16 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3D63A6E35 for ; Wed, 17 Jun 2009 04:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.021, 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 XYBDFAQ1VDIl for ; Wed, 17 Jun 2009 04:07:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4AE523A6DF5 for ; Wed, 17 Jun 2009 04:07:15 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 305E9C0045; Wed, 17 Jun 2009 13:07:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id E+eyFlzSqhhw; Wed, 17 Jun 2009 13:07:20 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D99DCC0042; Wed, 17 Jun 2009 13:07:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B5201B45778; Wed, 17 Jun 2009 13:07:18 +0200 (CEST) Date: Wed, 17 Jun 2009 13:07:18 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20090617110718.GD9086@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Benoit Claise , "Peter Lei (peterlei)" , Michael Tuexen , IETF IPFIX Working Group References: <4A3805EC.3010702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 11:07:16 -0000 On Wed, Jun 17, 2009 at 12:24:04PM +0200, Romascanu, Dan (Dan) wrote: > Yes, this is the type of information that I was looking for. My reading > of your answer is that the impact of adding SCTP streams in an existing > session versus opening a new SCTP session is minor, with a possible plus > of efficiency at setup time. Processing overhead and message overhead > may potentially be a problem, and care should be exercised in deployment > in order to understand the effects. The Security Considerations section of RFC 5101 suggests that IPFIX favours DTLS for SCTP instead of TLS for SCTP. I must admit that I have no clue what the state of the art currently is in defining DTLS usage for SCTP since I am not following the TSVWG. However, there is a significant difference in terms of overhead between having security on a per stream basis or having security on a per association basis. Perhaps this should be considered somewhere in the document if we like to discuss overhead. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 17 04:13:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658D03A6BAD for ; Wed, 17 Jun 2009 04:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 VeC34ER+yjOA for ; Wed, 17 Jun 2009 04:13:08 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 34B4A3A6BCB for ; Wed, 17 Jun 2009 04:13:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,235,1243828800"; d="scan'208";a="164541002" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 17 Jun 2009 07:13:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jun 2009 07:13:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 13:12:54 +0200 Message-ID: In-Reply-To: <20090617110718.GD9086@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD Review ofdraft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performanceand capacity Thread-Index: AcnvO8tGGSdI1BHkQqG1NA3s/A6zeAAAJ0rg References: <4A3805EC.3010702@cisco.com> <20090617110718.GD9086@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review ofdraft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performanceand capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 11:13:09 -0000 Good observation, I believe that this aspect needs to be investigated.=20 Dan =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, June 17, 2009 2:07 PM > To: Romascanu, Dan (Dan) > Cc: Benoit Claise; Peter Lei (peterlei); Michael Tuexen; IETF=20 > IPFIX Working Group > Subject: Re: [IPFIX] AD Review=20 > ofdraft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 > performanceand capacity >=20 > On Wed, Jun 17, 2009 at 12:24:04PM +0200, Romascanu, Dan (Dan) wrote: > =20 > > Yes, this is the type of information that I was looking for. My=20 > > reading of your answer is that the impact of adding SCTP=20 > streams in an=20 > > existing session versus opening a new SCTP session is minor, with a=20 > > possible plus of efficiency at setup time. Processing overhead and=20 > > message overhead may potentially be a problem, and care should be=20 > > exercised in deployment in order to understand the effects. >=20 > The Security Considerations section of RFC 5101 suggests that=20 > IPFIX favours DTLS for SCTP instead of TLS for SCTP. I must=20 > admit that I have no clue what the state of the art currently=20 > is in defining DTLS usage for SCTP since I am not following=20 > the TSVWG. However, there is a significant difference in=20 > terms of overhead between having security on a per stream=20 > basis or having security on a per association basis. > Perhaps this should be considered somewhere in the document=20 > if we like to discuss overhead. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From muenz@net.in.tum.de Wed Jun 17 04:52:38 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F74428C240 for ; Wed, 17 Jun 2009 04:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.181, 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 mBAN9ZbHlNzO for ; Wed, 17 Jun 2009 04:52:37 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id E207028C235 for ; Wed, 17 Jun 2009 04:52:36 -0700 (PDT) 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 C3ED947D26; Wed, 17 Jun 2009 13:52:42 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id AB4025409; Wed, 17 Jun 2009 13:52:42 +0200 (CEST) Message-ID: <4A38D95F.4090002@net.in.tum.de> Date: Wed, 17 Jun 2009 13:54:07 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Benoit Claise , "Peter Lei (peterlei)" , Michael Tuexen , IETF IPFIX Working Group References: <4A3805EC.3010702@cisco.com> <20090617110718.GD9086@elstar.local> In-Reply-To: <20090617110718.GD9086@elstar.local> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010000090906050705060003" X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 11:52:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010000090906050705060003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As far as I know, DTLS parameters are negotiated per SCTP association, not per stream, according to the current state of standardization. Regards, Gerhard Juergen Schoenwaelder wrote: > On Wed, Jun 17, 2009 at 12:24:04PM +0200, Romascanu, Dan (Dan) wrote: > =20 >> Yes, this is the type of information that I was looking for. My readin= g >> of your answer is that the impact of adding SCTP streams in an existin= g >> session versus opening a new SCTP session is minor, with a possible pl= us >> of efficiency at setup time. Processing overhead and message overhead >> may potentially be a problem, and care should be exercised in deployme= nt >> in order to understand the effects.=20 >=20 > The Security Considerations section of RFC 5101 suggests that IPFIX > favours DTLS for SCTP instead of TLS for SCTP. I must admit that I > have no clue what the state of the art currently is in defining DTLS > usage for SCTP since I am not following the TSVWG. However, there is a > significant difference in terms of overhead between having security on > a per stream basis or having security on a per association basis. > Perhaps this should be considered somewhere in the document if we > like to discuss overhead. >=20 > /js >=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 --------------ms010000090906050705060003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE3MTE1NDA3WjAjBgkqhkiG9w0BCQQxFgQU MdcHK1gmJb5gIdpyveppDHlou6wwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJSbaH2Z9qkaukTtCxxNiWJhiT350dup7zLSBwMla1wtKu9i tq4O7qFmye+fbBxy2hrVAUfGSnEggJHXnEqLd9x01z1Dk1fBKBQY8Af7O8tG1bNKTHfub4e3 cK+X+sHVH7qkJHUvealvcTrMstopZc2WJp5+wFgnz2E9YYQWQYzX7LaPlhMM8sY/NRdnVIzd CbatjiLHiuhswbpiJw+nE2KLu6jZXylecgWI4Ncx+oy9GANujy2InzcGi1zDGfZ7VXAVvapU /PhOxAZYLBguh+1GWdGu22CBMOsap5SkUTG/tUplktouzRnOP8npqhw7m9jDsgnqrlwHhofL 6TBwbu0AAAAAAAA= --------------ms010000090906050705060003-- From muenz@net.in.tum.de Wed Jun 17 05:43:20 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E84328C249 for ; Wed, 17 Jun 2009 05:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=1.135, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbtpEgSGq-Sv for ; Wed, 17 Jun 2009 05:43:19 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 3B59128C24F for ; Wed, 17 Jun 2009 05:43:19 -0700 (PDT) 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 0870548317; Wed, 17 Jun 2009 14:43:14 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id F033C1EF9; Wed, 17 Jun 2009 14:43:13 +0200 (CEST) Message-ID: <4A38E537.6080208@net.in.tum.de> Date: Wed, 17 Jun 2009 14:44:39 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> <4A38A423.8000804@cisco.com> In-Reply-To: <4A38A423.8000804@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050301050805050100000905" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:43:20 -0000 This is a cryptographically signed message in MIME format. --------------ms050301050805050100000905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, >>>> IPFIX Mediation >>>> >>>> IPFIX Mediation is a generic function that covers the manipula= tion >>>> =20 >>> remove "generic" ? >>> >>> =20 >>>> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >>>> Messages, or their transmission. The IPFIX Mediation offers o= ne >>>> =20 >>> Could be read as "covers the transmission of...", which would make an= >>> Exporting Process a Mediation function. >>> >>> Also, you sentence does not include "Options Data Records" (I put thi= s >>> in quotes because it is not an official term). >>> =20 >> >> Yes, indeed. >> =20 >>> maybe: >>> "...covers the manipulation of the content and transmission of Data >>> Records and IPFIX Messages." >>> =20 >> >> Fine. >> =20 > Actually, I have a problem with this proposal, i.e. adding > "transmission" in the IPFIX Mediation definition. Well, "transmission" was in the draft. It is not my wording. "transmission" relates to the translation of Netflow into IPFIX etc. Do to this, I assume that an Intermediate Process is needed because the records need to be converted. In fact, the function can be quite complex.= I'm open to better text covering such translations. Even "manipulation of Data Records" (in capital letters) is not precise because if we import from Netflow. Data Record is an IPFIX term. So, maybe just "manipulation and conversion of records"? > It doesn't fit with the following model (coming from the framework draf= t): >=20 > +---------------------------+ +---------------------------+ > | Collector {l} | | Collector {k} | > |[*Application(s)] | |[*Application(s)] | > |[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 to Observation Points >=20 > Where we make a clear distinction between the Intermediate Process and > the Exporting Process > The question is: can we have a Intermediate Process that is a Mediation= > Function, for example a IPFIX Concentrator, without exporting? > So a Mediation Function does not contain the export. >=20 > Double checking the terminology, I realize that there is a mistake: > OLD: >=20 > IPFIX Concentrator >=20 > An IPFIX Concentrator is a type of IPFIX Mediation that receives > Flow Records/Packet Reports, correlates them, aggregates them, or= > modifies them, then exports the new Data Records. >=20 > NEW: > IPFIX Concentrator >=20 > An IPFIX Concentrator is a type of IPFIX Mediation that receives > Flow Records/Packet Reports, correlates them, aggregates them, or= > modifies them _into new_ Data Records. >=20 >=20 >=20 >>>> or multiple of the following capabilities: >>>> >>>> * content mediation that changes Flow Records/Packet Reports >>>> information >>>> >>>> + aggregating Flow Records/Packet Reports based on a new s= et >>>> of Flow Key fields >>>> >>>> + correlating a set of Flow Records/Packet Reports >>>> >>>> + filtering and selecting Flow Records/Packet Reports >>>> >>>> + modifying Flow Records/Packet Reports, including: >>>> >>>> - changing the value of specified Information Elements >>>> >>>> - adding new Information Elements by deriving further F= low >>>> or packet properties from existing fields (for exampl= e: >>>> calculating new metrics or new counters) >>>> >>>> - deleting specified Information Elements >>>> =20 >>> in the whole definition: >>> s/Flow Records\/Packet Reports/Data Records >>> =20 > Then how do you stress that the the input can come from both IPFIX and > PSAMP? Data Record covers all of them: Flow Records, Packet Reports, Data Records associated to Option Templates. This is what is meant here, right= ? 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 --------------ms050301050805050100000905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE3MTI0NDM5WjAjBgkqhkiG9w0BCQQxFgQU +tNAyVGwCAxNFSNrmBJd9tSDpTUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGqJg3S6EH2Fa6bwZrhjD4ejQP28QYl7KpLcUIE4AtbQbgBm gmIxsp5tU4myYhrW6ejLRze8feN1r0IG1JDMKIOZJJdsETjIoTkUHofG0Cfk4aQ8mLTKOqpk bDJlsijHyuN30A9dTDDmB4Yyd0W1yKreU/BHEFg/ux5aLXNxvsg6qFcriefIPf4tX08OMe72 RTQBTxTjV3IDmUV8NfmmviIVOhrI8b01gv2j4JMY07icVnTAqEHNByjIVOSP59P1yo3Eobvl SoyMlN0M325RsoQa92a7w2Bt/8jxpCrmU56A0smV9Z+yM9HbmWY6W8vD9UwWFKlANrAkkiUI dID88s4AAAAAAAA= --------------ms050301050805050100000905-- From muenz@net.in.tum.de Wed Jun 17 05:59:27 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D393A6C71 for ; Wed, 17 Jun 2009 05:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.908, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS1Y3dV-gsH6 for ; Wed, 17 Jun 2009 05:59:26 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 991CB3A6B66 for ; Wed, 17 Jun 2009 05:59:25 -0700 (PDT) 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 243D648317; Wed, 17 Jun 2009 14:58:57 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 0F62F288A; Wed, 17 Jun 2009 14:58:57 +0200 (CEST) Message-ID: <4A38E8E5.3010507@net.in.tum.de> Date: Wed, 17 Jun 2009 15:00:21 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <4A1BE50E.6040407@net.in.tum.de> <4A389B20.6090308@cisco.com> <4A38A2BF.40000@net.in.tum.de> <4483866D-79AC-4094-A7EF-F274CDB1A441@tik.ee.ethz.ch> <4A38BB8E.7030901@cisco.com> In-Reply-To: <4A38BB8E.7030901@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060807070905050608020100" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:59:27 -0000 This is a cryptographically signed message in MIME format. --------------ms060807070905050608020100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Benoit, Benoit Claise wrote: >>>>> *IPFIX Mediation* >>>>> =3D a function >>>>> >>>>> *IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX Distributor* >>>>> =3D specific types of IPFIX Mediation >>> >>> =3D> specific type of IPFIX Mediator (i.e., this is a device, not a >>> function) >>> >>> This does not yet solve the complicated language w/r to >>> separate/original exporter, but is inline with RFC3917. >> >> It also doesn't fix a problem in the Implementation Analysis >> subsections, that suggest the solutions to problems by applying >> various IPFIX Mediator devices. The suggestion here seems to be that >> it is the _devices_ that are important (use a concentrator, use a >> proxy), not the _functions_. This seems wrong, _especially_ at the >> level at which the problem statement should be. It's the functions >> that are important here. HOW to execute them is a detail for the >> framework and drafts below it. I agree. One question is how to call these "functions" (terminology should fit into the scheme). IMO, terms like "IPFIX Concentrator", "IPFIX Proxy" do not fit because they are already used in the context of devices. I would be satisfied with terms like "Concentrator Function", "Proxy Function" et= c. Brian raised another question (below) whether we need to define specific terms for these functions in the problem statement. I guess the answer is no because the functions represent _solutions_ , not _problems_ we want to describe. >> (e.g., the early binding to devices seems to imply that if I want to, >> say, accept both V9 and IPFIX data and forward summary aggregation >> data to a downstream collector, I need to rack three boxes at the >> mediation point according to the problem statement. This seems... >> inappropriately detailed, and incorrect.) > > Exactly, this is the topic of my previous email. > >> This implies we should also step back and re-examine the boundary >> between the problem statement and framework, and move the appropriate >> terminology and explanation to the appropriate place. >> >>>>> *IPFIX Mediator* >>>>> =3D devices that implements IPFIX Mediation >>> >>> I think this is a good plan. >> >> As do I, subject to the consideration above. :) As stated above, "IPFIX Concentrator" etc. do not sound like a _function_ names to me. Therefore, I do not like the current definitions of these terms. [...] >>>> This is where we're going, if you look at figure B of >>>> http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-02 >>>> >>>> IPFIX (Flow Records / Packet Reports) >>>> ^ >>>> ^ | >>>> +------------------------|-|---------------------+ >>>> | IPFIX Mediator | | | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Exporting Process(es) |' | >>>> | '----------------------^--------------------' | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Intermediate Process(es) (optional) |' | >>>> | '----------------------^--------------------' | >>>> | | | | >>>> | .---------------------|-+-------------------. | >>>> | .----------------------+--------------------.| | >>>> | | Collecting Process(es) |' | >>>> | '----------------------^--------------------' | >>>> +------------------------|-|---------------------+ >>>> | >>>> IPFIX (Flow Records / Packet Reports) >>>> >>>> So the intermediate process hosts one of several functions defined >>>> below or a combination of them, in any sequence or in any set. >>>> >>>> >>>> 5.3.1 >>>> .=20 >>>> Selection Function . . . . . . . . . . . . . . . . . . 10 >>>> >>>> >>>> 5.3.2 >>>> .=20 >>>> Aggregation Function . . . . . . . . . . . . . . . . . 12 >>>> >>>> >>>> 5.3.3 >>>> .=20 >>>> Correlation Function . . . . . . . . . . . . . . . . . 13 >>>> >>>> >>>> 5.3.4 >>>> .=20 >>>> Modification Function . . . . . . . . . . . . . . . . 14 >>>> >>>> >>>> ... to define the IPFIX Concentrator, IPFIX (Masq.) Proxy, IPFIX >>>> Distributor, etc... >>>> >>>> >>>> The question is: should describe the processes in the problem statem= ent >>>> draft? We've been going back and forth. I think it makes more sense = in >>>> the framework draft. This would be in line between the RFC3917 and t= he >>>> IPFIX architecture RFC5470. >> >> I would tend to think they go in the framework draft, as well; but >> then the problem statement should really be limited to talking about >> the _types of functions_ (without Capital Letter Terminology) that are= >> required to meet the challenges posed by each specific situation. But >> then, any discussion of devices should be generalized, and moved to >> the Framework as well. I like this proposal. It implies that we remove the terms IPFIX Proxy IPFIX Concentrator IPFIX Distributor IPFIX Masquerading Proxy from the terminology section of the problem statement draft. >>>> Coming back to your questions: >>>> >>>> - On the one hand, you have troubles to distinguish between IPFIX= >>>> Mediation implemented at an "Original Exporter" and IPFIX Mediati= on >>>> implemented at a "separate IPFIX Mediator/Concentrator/...". >>>> >>>> This is what we showed in the figures B and C of the framework draft= >>>> >>>> >>>> - On the other hand, the terms do not fit into the current >>>> terminology >>>> scheme of IPFIX and PSAMP, where we are used to "XXX Process" >>>> when we >>>> talk about the instantiation of a specific function. >>>> >>>> I think it will with the framework draft. >>>> >>>> Does it make sense? >> >> Yes. Subject to either of the following arrangements: >> >> 1. there is only one type of Intermediate Process, which can host any >> number of Mediation Functions (this makes the most sense from the >> implementation point of view), or As already pointed out in previous mails, I prefer this approach because it follows the same concept as in PSAMP. Gerhard >> 2. there exists a type of Intermediate Process for each basic function= >> (an Intermediate Aggregation Process, an Intermediate Selection >> Process, and so on; this makes the most sense from a formalization >> point of view)... > We could go either way, but I guess that the future drafts specifying > specific mediation functions would prefer the latter. >=20 > Regards, Benoit. --=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 --------------ms060807070905050608020100 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE3MTMwMDIxWjAjBgkqhkiG9w0BCQQxFgQU sLmleed+a1qmxaSOLatlMlE9KEwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAKfqIGJtqW+Oe1ivLorsZrKXHNwhUvrsP43DBxO/0hC/Phg3 amhtJnwATGGixDNgSDtuuyMXQ0n0x/dTNbVXX1NinRclfKXxB/DzjX9gumHtMmTitweHu2oo vX3r7UcgNYnwhlz9vUVgMuCAav3wihbcenqsfuwIkA6B51s+NwbS3SLfDZ0KShdUbpCFU1sc vKLBPJgcaPcKVtasNY7Br+FfpQVxNqsipgHJaxBvfGEjOebTk0r5xQ70ARj4Vwlev54O/uX8 QybCqOZTvyK+3aIXzLKfELvdpE4o4qj6X++g7edj68+k1H5NUnVO4S7kcN56eA41LmR1dJ8J +5G7XQMAAAAAAAA= --------------ms060807070905050608020100-- From muenz@net.in.tum.de Wed Jun 17 06:39:44 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427F228C28B for ; Wed, 17 Jun 2009 06:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.243, 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 RMOlP382mEHY for ; Wed, 17 Jun 2009 06:39:42 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 7D3B73A6846 for ; Wed, 17 Jun 2009 06:39:07 -0700 (PDT) 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 80E0447D26; Wed, 17 Jun 2009 15:38:51 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 6149D50BC; Wed, 17 Jun 2009 15:38:51 +0200 (CEST) Message-ID: <4A38F240.4000305@net.in.tum.de> Date: Wed, 17 Jun 2009 15:40:16 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070402080205040009030707" X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:39:44 -0000 This is a cryptographically signed message in MIME format. --------------ms070402080205040009030707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Thomas, Paul, Andrew, Atsushi, I've been thinking a little bit more about the way how OPs, SPs, Caches, and EPs are linked together in the MIB and in the config model. At the moment, the config model enables configurations in which a Cache maintains records generated of packets observed at different Observation Domains and/or selected by different Selection Processes. Example: OP1 -> SP1 -+ +-> Cache -> EP OP2 -> SP2 -+ However, packets of different OD or from different SPs MUST NOT be accounted in the same record. Consequently, the Cache must implicitly treat ODID and Selection Sequence ID as additional flow keys. Is this acceptable? Or should we inhibit such configurations and ensure by specification of the config model that all packets entering a Cache come from the same OD and have passed the identical Selection Processes? If the answer to the second question is yes, we can change the model as follows: Instead of specifying where the output of an OP, SP, Cache goes,... OP -> SP -> Cache -> EP =2E..we specify where the input comes from: OP <- SP <- Cache <- EP This means that we invert the direction of the references. We can specify that SPs and Caches have a maximum of one input. This ensures that packets entering the Cache come from a single SP, and packets entering this SP come from a single OP. Instead of OP, we can adopt ObservationPointGroup (as used in the MIB) to specify a group of OPs belonging to the same OD. Only for the EP, we allow multiple inputs from different Caches. Hence, configurations like this are possible: +- Cache1 <-+ +- SP1 <-+ | OPG <-+ +- Cache2 <-+- EP | | +- SP2 <--- Cache3 <-+ The disadvantage is that the linkage is done in the reverse direction of the actual "data flow". The advantage is that we can quite easily realize the same linkage in the MIB using indexes. The changes in the MIB would be relatively small. If we decided to go this way, it should be done quickly such that we can adapt the indexing in the MIB. 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 --------------ms070402080205040009030707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE3MTM0MDE2WjAjBgkqhkiG9w0BCQQxFgQU 16JLy2UpAzyeia+R1023dp0hE/0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGTjazM/4xFJZMKv2WaWrnX2Tpi1+Xg+iAZlo15vEtviVVg4 UAg6DXGHoCVDiOx39rrCP+PpEkA+/KUMAa4v0bGmzDirN0hc3pLFLTUut2S4oibN3Rqsd8Yl PiDMTQo69TrcOQrZArKtsYTM5uzasK+BeFcf7NrOGrPzTshCXdaFtqDSloXA5HwG+F9NOve9 dOP54Y5hF4VmDaz6h+ZnhTSnwNYGFiMpTgNFoM+BHqwBkeVPwRhhkjK7SWZQW440i81lIVpv MXRSsYjdTMfWOb7dQszH5A7S6x7IgMnxXkl6fLTLdSKbmfPjxmmZQrWWEqdUv5/ImsE3TJ1x Am29XMQAAAAAAAA= --------------ms070402080205040009030707-- From bclaise@cisco.com Wed Jun 17 06:39:45 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A075D3A6846 for ; Wed, 17 Jun 2009 06:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.605 X-Spam-Level: X-Spam-Status: No, score=-3.605 tagged_above=-999 required=5 tests=[AWL=0.993, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ox7A348kdQi6 for ; Wed, 17 Jun 2009 06:39:44 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 796EF28C283 for ; Wed, 17 Jun 2009 06:39:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5HDd235006172; Wed, 17 Jun 2009 15:39:02 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5HDd1NK014781; Wed, 17 Jun 2009 15:39:01 +0200 (CEST) Message-ID: <4A38F1F4.5030706@cisco.com> Date: Wed, 17 Jun 2009 15:39:00 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> <4A38A423.8000804@cisco.com> <4A38E537.6080208@net.in.tum.de> In-Reply-To: <4A38E537.6080208@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------030903080301070505040003" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:39:45 -0000 This is a multi-part message in MIME format. --------------030903080301070505040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard Muenz wrote: > Benoit, > > >>>>> IPFIX Mediation >>>>> >>>>> IPFIX Mediation is a generic function that covers the manipulation >>>>> >>>>> >>>> remove "generic" ? >>>> >>>> >>>> >>>>> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >>>>> Messages, or their transmission. The IPFIX Mediation offers one >>>>> >>>>> >>>> Could be read as "covers the transmission of...", which would make an >>>> Exporting Process a Mediation function. >>>> >>>> Also, you sentence does not include "Options Data Records" (I put this >>>> in quotes because it is not an official term). >>>> >>>> >>> Yes, indeed. >>> >>> >>>> maybe: >>>> "...covers the manipulation of the content and transmission of Data >>>> Records and IPFIX Messages." >>>> >>>> >>> Fine. >>> >>> >> Actually, I have a problem with this proposal, i.e. adding >> "transmission" in the IPFIX Mediation definition. >> > > Well, "transmission" was in the draft. It is not my wording. > Right. Sorry. The draft version 3 says IPFIX Mediation IPFIX Mediation is a generic function that covers the manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages, or their transmission. The proposal in this thread is: "...covers the manipulation of the content _and _transmission of Data Records and IPFIX Messages." The difference now is "and". This means that we always "transmit" in the mediation If "transmit" is perceived as "exported", then I have a problem > "transmission" relates to the translation of Netflow into IPFIX etc. > Do to this, I assume that an Intermediate Process is needed because the > records need to be converted. In fact, the function can be quite complex. > > I'm open to better text covering such translations. Even "manipulation > of Data Records" (in capital letters) is not precise because if we > import from Netflow. Data Record is an IPFIX term. > > So, maybe just "manipulation and conversion of records"? > That makes more sense to me, and would be in line with the framework, where the Exporting Process is a different process > > >> It doesn't fit with the following model (coming from the framework draft): >> >> +---------------------------+ +---------------------------+ >> | Collector {l} | | Collector {k} | >> |[*Application(s)] | |[*Application(s)] | >> |[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 to Observation Points >> >> Where we make a clear distinction between the Intermediate Process and >> the Exporting Process >> The question is: can we have a Intermediate Process that is a Mediation >> Function, for example a IPFIX Concentrator, without exporting? >> So a Mediation Function does not contain the export. >> >> Double checking the terminology, I realize that there is a mistake: >> OLD: >> >> IPFIX Concentrator >> >> An IPFIX Concentrator is a type of IPFIX Mediation that receives >> Flow Records/Packet Reports, correlates them, aggregates them, or >> modifies them, then exports the new Data Records. >> >> NEW: >> IPFIX Concentrator >> >> An IPFIX Concentrator is a type of IPFIX Mediation that receives >> Flow Records/Packet Reports, correlates them, aggregates them, or >> modifies them _into new_ Data Records. >> >> >> >> >>>>> or multiple of the following capabilities: >>>>> >>>>> * content mediation that changes Flow Records/Packet Reports >>>>> information >>>>> >>>>> + aggregating Flow Records/Packet Reports based on a new set >>>>> of Flow Key fields >>>>> >>>>> + correlating a set of Flow Records/Packet Reports >>>>> >>>>> + filtering and selecting Flow Records/Packet Reports >>>>> >>>>> + modifying Flow Records/Packet Reports, including: >>>>> >>>>> - changing the value of specified Information Elements >>>>> >>>>> - adding new Information Elements by deriving further Flow >>>>> or packet properties from existing fields (for example: >>>>> calculating new metrics or new counters) >>>>> >>>>> - deleting specified Information Elements >>>>> >>>>> >>>> in the whole definition: >>>> s/Flow Records\/Packet Reports/Data Records >>>> >>>> >> Then how do you stress that the the input can come from both IPFIX and >> PSAMP? >> > > Data Record covers all of them: Flow Records, Packet Reports, Data > Records associated to Option Templates. This is what is meant here, right? > Sure. Actually, if we keep "manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages" in the IPFIX Mediation first sentences, then we don't need to repeat "Flow Records/Packet Reports" further down in the examples, and the IPFIX Concentrator, IPFIX Masquerading Proxy (since their definitions are derived from IPFIX Mediation). I'm convinced now Regards, Benoit > Gerhard > > > --------------030903080301070505040003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard Muenz wrote: 
Benoit,

  
   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      
          
remove "generic" ?

    
        
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.  The IPFIX Mediation offers one
      
          
Could be read as "covers the transmission of...", which would make an
Exporting Process a Mediation function.

Also, you sentence does not include "Options Data Records" (I put this
in quotes because it is not an official term).
    
        
Yes, indeed.
  
      
maybe:
"...covers the manipulation of the content and transmission of Data
Records and IPFIX Messages."
    
        
Fine.
  
      
Actually, I have a problem with this proposal, i.e. adding
"transmission" in the IPFIX Mediation definition.
    

Well, "transmission" was in the draft. It is not my wording.
Right. Sorry.
The draft version 3 says
   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX
      Messages, or their transmission.
The proposal in this thread is:
"...covers the manipulation of the content and transmission of Data
Records and IPFIX Messages."
The difference now is "and". This means that we always "transmit" in the mediation
If "transmit" is perceived as "exported", then I have a problem
"transmission" relates to the translation of Netflow into IPFIX etc.
Do to this, I assume that an Intermediate Process is needed because the
records need to be converted. In fact, the function can be quite complex.

I'm open to better text covering such translations. Even "manipulation
of Data Records" (in capital letters) is not precise because if we
import from Netflow. Data Record is an IPFIX term.

So, maybe just "manipulation and conversion of records"?
That makes more sense to me, and would be in line with the framework, where the Exporting Process is a different process

  
It doesn't fit with the following model (coming from the framework draft):

   +---------------------------+    +---------------------------+
   | Collector {l}             |    | Collector {k}             |
   |[*Application(s)]          |    |[*Application(s)]          |
   |[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 to Observation Points

Where we make a clear distinction between the Intermediate Process and
the Exporting Process
The question is: can we have a Intermediate Process that is a Mediation
Function, for example a IPFIX Concentrator, without exporting?
So a Mediation Function does not contain the export.

Double checking the terminology, I realize that there is a mistake:
OLD:

   IPFIX Concentrator

      An IPFIX Concentrator is a type of IPFIX Mediation that receives
      Flow Records/Packet Reports, correlates them, aggregates them, or
      modifies them, then exports the new Data Records.

NEW:
   IPFIX Concentrator

      An IPFIX Concentrator is a type of IPFIX Mediation that receives
      Flow Records/Packet Reports, correlates them, aggregates them, or
      modifies them _into new_ Data Records.



    
      or multiple of the following capabilities:

      *  content mediation that changes Flow Records/Packet Reports
         information

         +  aggregating Flow Records/Packet Reports based on a new set
            of Flow Key fields

         +  correlating a set of Flow Records/Packet Reports

         +  filtering and selecting Flow Records/Packet Reports

         +  modifying Flow Records/Packet Reports, including:

            -  changing the value of specified Information Elements

            -  adding new Information Elements by deriving further Flow
               or packet properties from existing fields (for example:
               calculating new metrics or new counters)

            -  deleting specified Information Elements
      
          
in the whole definition:
s/Flow Records\/Packet Reports/Data Records
    
        
Then how do you stress that the the input can come from both IPFIX and
PSAMP?
    

Data Record covers all of them: Flow Records, Packet Reports, Data
Records associated to Option Templates. This is what is meant here, right?
Sure.

Actually, if we keep "manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages" in the IPFIX Mediation first sentences, then we don't need to repeat "Flow Records/Packet Reports" further down in the examples, and the IPFIX Concentrator, IPFIX Masquerading Proxy (since their definitions are derived from IPFIX Mediation).

I'm convinced now

Regards, Benoit
Gerhard

--------------030903080301070505040003-- From andrjohn@cisco.com Wed Jun 17 06:54:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD0A63A6B80 for ; Wed, 17 Jun 2009 06:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCScgUZUWB0Q for ; Wed, 17 Jun 2009 06:54:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 745CF3A693F for ; Wed, 17 Jun 2009 06:54:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,236,1243814400"; d="scan'208";a="43022811" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jun 2009 13:53:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5HDrIMn002175; Wed, 17 Jun 2009 15:53:18 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5HDrIaB022306; Wed, 17 Jun 2009 13:53:18 GMT Received: from [144.254.153.42] (dhcp-144-254-153-42.cisco.com [144.254.153.42]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n5HDrHm13229; Wed, 17 Jun 2009 14:53:17 +0100 (BST) Message-ID: <4A38F560.8020205@cisco.com> Date: Wed, 17 Jun 2009 14:53:36 +0100 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Gerhard Muenz References: <4A38F240.4000305@net.in.tum.de> In-Reply-To: <4A38F240.4000305@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2849; t=1245246798; x=1246110798; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Common=20structure=20for=20IPFIX-MIB=20 +=20IPFIX-CONFIG |Sender:=20; bh=vICKFA5HYrXP7VJHoNOBF8keA3Hsjl3+O+ZOuaTPxs4=; b=WDuPlVACDJl5t0+ijoYU5JN+vtt7ybvZGwkgBu5OeOIMTj1/PyiRlDD7C8 8UpAtzBecJBviwPCAuDVvo+lEf1nQbC9TaT/gSBje4VsPBYXC0ImUX19+U85 AyV6vn5XFq; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:54:24 -0000 Hi Gerhard The definition of an Observation Domain is: An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. By it's very definition a cache cannot monitor packets from different Observation Domains and configuring it should be impossible, not because of a limit of the configuration model, but because all Observation Points available to a cache are defined to be part of the same Observation Domain. Cheers Andrew Gerhard Muenz wrote: > Benoit, Thomas, Paul, Andrew, Atsushi, > > I've been thinking a little bit more about the way how OPs, SPs, Caches, > and EPs are linked together in the MIB and in the config model. > > At the moment, the config model enables configurations in which a Cache > maintains records generated of packets observed at different > Observation Domains and/or selected by different Selection Processes. > > Example: > > OP1 -> SP1 -+ > +-> Cache -> EP > OP2 -> SP2 -+ > > However, packets of different OD or from different SPs MUST NOT be > accounted in the same record. Consequently, the Cache must implicitly > treat ODID and Selection Sequence ID as additional flow keys. > > Is this acceptable? > > Or should we inhibit such configurations and ensure by specification of > the config model that all packets entering a Cache come from the same OD > and have passed the identical Selection Processes? > > If the answer to the second question is yes, we can change the model as > follows: > > Instead of specifying where the output of an OP, SP, Cache goes,... > > OP -> SP -> Cache -> EP > > ...we specify where the input comes from: > > OP <- SP <- Cache <- EP > > This means that we invert the direction of the references. > > We can specify that SPs and Caches have a maximum of one input. This > ensures that packets entering the Cache come from a single SP, and > packets entering this SP come from a single OP. > > Instead of OP, we can adopt ObservationPointGroup (as used in the MIB) > to specify a group of OPs belonging to the same OD. > > Only for the EP, we allow multiple inputs from different Caches. > > Hence, configurations like this are possible: > > +- Cache1 <-+ > +- SP1 <-+ | > OPG <-+ +- Cache2 <-+- EP > | | > +- SP2 <--- Cache3 <-+ > > The disadvantage is that the linkage is done in the reverse direction of > the actual "data flow". > The advantage is that we can quite easily realize the same linkage in > the MIB using indexes. The changes in the MIB would be relatively small. > > If we decided to go this way, it should be done quickly such that we can > adapt the indexing in the MIB. > > Regards, > Gerhard > From Quittek@nw.neclab.eu Wed Jun 17 12:25:43 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C0728C2DF; Wed, 17 Jun 2009 12:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkVs+WR-Bn-b; Wed, 17 Jun 2009 12:25:41 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id B9A9F28C2DA; Wed, 17 Jun 2009 12:25:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id F17B52C01C8EC; Wed, 17 Jun 2009 21:25:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtcBX52wiG8Q; Wed, 17 Jun 2009 21:25:51 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B12422C019196; Wed, 17 Jun 2009 21:25:31 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jun 2009 19:25:31 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3328118500_1049239" Date: Wed, 17 Jun 2009 21:21:40 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter Thread-Index: AcnvgNcTDmN0YTA0zUKyt9t4T6yGqA== From: "Juergen Quittek" To: "Dan Romascanu" Cc: IETF PSAMP Working Group , Nevil Brownlee , IETF IPFIX Working Group Subject: [IPFIX] Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 19:25:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328118500_1049239 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dan and Ron, I'm writing you with two hats on, the one of the PSAMP WG chair and the one of the IPFIX WG co-chair. As discussed at the IPFIX session in San Francisco, we plan to conclude the PSAMP WG and move the one remaining work item to the IPFIX WG. The PSAMP WG has published all its planned documents except for the PSAMP MIB module. It does not seem reasonable to keep the WG alive just for finishing this single document. Most of the PSAMP WG members are also members of the IPFIX WG. The remaining work can be completed in the IPFIX WG. Therefore I propose to conclude the PSAMP WG and at the same time to extend the IPFIX WG charter by adding the following text: 6. The PSAMP WG has developed a protocol for reporting observed packets. The PSAMP protocol is an extension of the IPFIX protocol. The IPFIX WG will develop a MIB module for monitoring PSAMP implementations. The new MIB module will be an extension of the IPFIX MIB module. with the new milestones Jan 2010 Submit final version of PSAMP MIB module In the current PSAMP charter, the PSAMP MIB module work item is described as follows: 6. Configuration and Management. Define a packet sampler MIB to reside at the network element, including parameters for packet selection, packet report and stream format, and export. Select or define a communication protocol to configure/read this MIB. This old text included monitoring and configuration. However, the PSAMP WG as well as the IPFIX WG have consensus on using MIB modules rather for monitoring than for configuration. Configuration of PSAMP implementations is already covered by an existing IPFIX work item: the Configuration Data Model for IPFIX and PSAMP (draft-ietf-ipfix-configuration-model). Therefore, the item to be added to the IPFIX charter would cover monitoring only. The suggested extension of the IPFIX charter was discussed at the last IPFIX session in San Francisco without any objection. Thanks, Juergen --B_3328118500_1049239 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQsrF6mIU+lGsnRlS3e M1CPZ3Uk4jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTcxOTIxNDBaMA0GCSqGSIb3DQEBAQUABIIBAAAp+5F1sbgKSU47tX8lcEQ9BZisXGTb+9i4 332XtoeC9e0N4E7Z7wuUTe5jQXUtoqyrrf47QLQ1juqrNRHbmf3zxoXiJXjNE54T84N+FwY3 5ROCBLCrLtJ7J1wOi/wtET7dmQqXMaFyeSnqYyM+JyUKmRT0YFMAoGTbdpY/YJa7zEJo5HYL AhWW+tlsHAh4cIPAyuTvzt1OwPJpS3dscldqwLdV2CP29+b2HjVh4mOIzKJYVmA2MQ0HCd3y 8hacHTr3XJVTeXUKUXDyKpSI+ECLVBmBJeafBIc+I8Ah+pafwiOrkdqNSGxOVVSgXeDqv19I vwGIO9qrF+AoZjmI+/Y= --B_3328118500_1049239-- From dromasca@avaya.com Wed Jun 17 13:42:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1293A6AD4; Wed, 17 Jun 2009 13:42:25 -0700 (PDT) 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.150, 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 20HUld9gWdX1; Wed, 17 Jun 2009 13:42:24 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7E2063A6AB4; Wed, 17 Jun 2009 13:42:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,239,1243828800"; d="scan'208";a="174269126" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2009 16:42:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Jun 2009 16:42:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 22:42:22 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter Thread-Index: AcnvgNcTDmN0YTA0zUKyt9t4T6yGqAACap7A References: From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" Cc: IETF PSAMP Working Group , Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 20:42:25 -0000 This is fine and I support the move.=20 Can you please forward me a revised IPFIX charter with the PSAMP MIB added? It would be a good opportunity to adjust milestones if necessary.=20 Dan =20 > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@nw.neclab.eu]=20 > Sent: Wednesday, June 17, 2009 10:22 PM > To: Romascanu, Dan (Dan) > Cc: Nevil Brownlee; IETF PSAMP Working Group; IETF IPFIX Working Group > Subject: Concluding the PSAM WG and moving the remaining work=20 > item to the IPFIX WG charter >=20 > Dear Dan and Ron, >=20 > I'm writing you with two hats on, the one of the PSAMP WG=20 > chair and the one of the IPFIX WG co-chair. >=20 > As discussed at the IPFIX session in San Francisco, we plan=20 > to conclude the PSAMP WG and move the one remaining work item=20 > to the IPFIX WG. >=20 > The PSAMP WG has published all its planned documents except=20 > for the PSAMP MIB module. It does not seem reasonable to keep=20 > the WG alive just for finishing this single document. Most=20 > of the PSAMP WG members are also members of the IPFIX WG. > The remaining work can be completed in the IPFIX WG. >=20 > Therefore I propose to conclude the PSAMP WG and at the same=20 > time to extend the IPFIX WG charter by adding the following text: >=20 > 6. The PSAMP WG has developed a protocol for reporting > observed packets. The PSAMP protocol is an extension of > the IPFIX protocol. The IPFIX WG will develop a MIB module > for monitoring PSAMP implementations. The new MIB module > will be an extension of the IPFIX MIB module. >=20 > with the new milestones >=20 > Jan 2010 Submit final version of PSAMP MIB module >=20 >=20 > In the current PSAMP charter, the PSAMP MIB module work item=20 > is described as follows: >=20 > 6. Configuration and Management. Define a packet sampler > MIB to reside at the network element, including parameters > for packet selection, packet report and stream format, > and export. Select or define a communication protocol to > configure/read this MIB. >=20 > This old text included monitoring and configuration. However,=20 > the PSAMP WG as well as the IPFIX WG have consensus on using=20 > MIB modules rather for monitoring than for configuration. > Configuration of PSAMP implementations is already covered by=20 > an existing IPFIX work item: the Configuration Data Model for=20 > IPFIX and PSAMP (draft-ietf-ipfix-configuration-model). > Therefore, the item to be added to the IPFIX charter would=20 > cover monitoring only. >=20 > The suggested extension of the IPFIX charter was discussed at=20 > the last IPFIX session in San Francisco without any objection. >=20 > Thanks, >=20 > Juergen >=20 From tuexen@fh-muenster.de Wed Jun 17 08:02:56 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8C73A6A7A for ; Wed, 17 Jun 2009 08:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qst83R-arDS6 for ; Wed, 17 Jun 2009 08:02:55 -0700 (PDT) Received: from dvz-002.fh-muenster.de (dvz-002.fh-muenster.de [193.174.88.2]) by core3.amsl.com (Postfix) with ESMTP id 2C5B03A69CD for ; Wed, 17 Jun 2009 08:02:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by dvz-002.fh-muenster.de (Postfix) with ESMTP id D6F521CC3AE; Wed, 17 Jun 2009 16:59:32 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at dvz-002.fh-muenster.de Received: from dvz-002.fh-muenster.de ([127.0.0.1]) by localhost (dvz-002.fh-muenster.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZU09IiPMBBZ; Wed, 17 Jun 2009 16:59:32 +0200 (CEST) Received: from DN0a160373.SUNet (unknown [38.114.142.90]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by dvz-002.fh-muenster.de (Postfix) with ESMTP id D18201CC3A4; Wed, 17 Jun 2009 16:59:26 +0200 (CEST) Message-Id: <163AC4BF-04C2-4C12-B8DC-B35AD715EAAC@fh-muenster.de> From: Michael Tuexen To: Juergen Schoenwaelder In-Reply-To: <20090617110718.GD9086@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 08:01:27 -0700 References: <4A3805EC.3010702@cisco.com> <20090617110718.GD9086@elstar.local> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Wed, 17 Jun 2009 14:23:10 -0700 Cc: "Peter Lei \(peterlei\)" , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:02:56 -0000 On Jun 17, 2009, at 4:07 AM, Juergen Schoenwaelder wrote: > On Wed, Jun 17, 2009 at 12:24:04PM +0200, Romascanu, Dan (Dan) wrote: > >> Yes, this is the type of information that I was looking for. My >> reading >> of your answer is that the impact of adding SCTP streams in an >> existing >> session versus opening a new SCTP session is minor, with a possible >> plus >> of efficiency at setup time. Processing overhead and message overhead >> may potentially be a problem, and care should be exercised in >> deployment >> in order to understand the effects. > > The Security Considerations section of RFC 5101 suggests that IPFIX > favours DTLS for SCTP instead of TLS for SCTP. I must admit that I > have no clue what the state of the art currently is in defining DTLS > usage for SCTP since I am not following the TSVWG. However, there is a > significant difference in terms of overhead between having security on > a per stream basis or having security on a per association basis. > Perhaps this should be considered somewhere in the document if we > like to discuss overhead. Since IPFIX uses PR-SCTP you can not use TLS/SCTP since it does not work with PR-SCTP. One should not use TLS/SCTP, since I'm not aware of any implementation of it and you really can not implement it in OpenSSL without a larger change of the infrastructure. We do have an implementation of DTLS/SCTP in OpenSSL, so it * supports SCTP including PR-SCTP and unordered chunks * is actually implementable. Best regards Michael > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From muenz@net.in.tum.de Thu Jun 18 00:36:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44CE63A6A38 for ; Thu, 18 Jun 2009 00:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 oDZy19ctkTG2 for ; Thu, 18 Jun 2009 00:36:49 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id D22963A6BCA for ; Thu, 18 Jun 2009 00:36:47 -0700 (PDT) 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 48BC64855E; Thu, 18 Jun 2009 09:36:56 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3510950D9; Thu, 18 Jun 2009 09:36:56 +0200 (CEST) Message-ID: <4A39EEED.1050501@net.in.tum.de> Date: Thu, 18 Jun 2009 09:38:21 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Johnson References: <4A38F240.4000305@net.in.tum.de> <4A38F560.8020205@cisco.com> In-Reply-To: <4A38F560.8020205@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000809010701070002050805" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 07:36:51 -0000 This is a cryptographically signed message in MIME format. --------------ms000809010701070002050805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Andrew, all, Andrew Johnson wrote: > The definition of an Observation Domain is: > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. >=20 > By it's very definition a cache cannot monitor packets from different > Observation Domains and configuring it should be impossible, not > because of a limit of the configuration model, but because all > Observation Points available to a cache are defined to be part of the > same Observation Domain. Thanks for pointing this out. We define a Cache as part of one Monitoring Process. With the definition of the Observation Domain, this excludes that packets of several ODs enter the same Cache. I do not see any need to change this. Currently, there is no such restriction for Selection Sequences. Am I right that PSAMP Selection Sequence Report Interpretation, Selection Sequence Statistics Report, etc. are to be used regardless of whether Packet Reports or Flow Records are generated by the Metering Process? If yes, packets that have been selected by different Selection Sequences must not be aggregated in the same Flow Records. The changes I proposed enforce that the input of a Cache is restricted to packets originating from one OD and selected by one Selection Sequence= =2E It is not possible (or would at least be very complicated) to achieve the same restriction with the current config model using the YANG formalism. We could only specify this in description clauses. With the proposed changes, invalid configurations are not possible by specification of the config model. (of course, the YANG module can be augmented if somebody really wants to do strange things) I would appreciate some more feedback on this. Regards, Gerhard > Gerhard Muenz wrote: >> Benoit, Thomas, Paul, Andrew, Atsushi, >> >> I've been thinking a little bit more about the way how OPs, SPs, Cache= s, >> and EPs are linked together in the MIB and in the config model. >> >> At the moment, the config model enables configurations in which a Cach= e >> maintains records generated of packets observed at different >> Observation Domains and/or selected by different Selection Processes. >> >> Example: >> >> OP1 -> SP1 -+ >> +-> Cache -> EP >> OP2 -> SP2 -+ >> >> However, packets of different OD or from different SPs MUST NOT be >> accounted in the same record. Consequently, the Cache must implicitly >> treat ODID and Selection Sequence ID as additional flow keys. >> >> Is this acceptable? >> >> Or should we inhibit such configurations and ensure by specification o= f >> the config model that all packets entering a Cache come from the same = OD >> and have passed the identical Selection Processes? >> >> If the answer to the second question is yes, we can change the model a= s >> follows: >> >> Instead of specifying where the output of an OP, SP, Cache goes,... >> >> OP -> SP -> Cache -> EP >> >> ...we specify where the input comes from: >> >> OP <- SP <- Cache <- EP >> >> This means that we invert the direction of the references. >> >> We can specify that SPs and Caches have a maximum of one input. This >> ensures that packets entering the Cache come from a single SP, and >> packets entering this SP come from a single OP. >> >> Instead of OP, we can adopt ObservationPointGroup (as used in the MIB)= >> to specify a group of OPs belonging to the same OD. >> >> Only for the EP, we allow multiple inputs from different Caches. >> >> Hence, configurations like this are possible: >> >> +- Cache1 <-+ >> +- SP1 <-+ | >> OPG <-+ +- Cache2 <-+- EP >> | | >> +- SP2 <--- Cache3 <-+ >> >> The disadvantage is that the linkage is done in the reverse direction = of >> the actual "data flow". >> The advantage is that we can quite easily realize the same linkage in >> the MIB using indexes. The changes in the MIB would be relatively smal= l. >> >> If we decided to go this way, it should be done quickly such that we c= an >> adapt the indexing in the MIB. >> >> 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 --------------ms000809010701070002050805 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE4MDczODIxWjAjBgkqhkiG9w0BCQQxFgQU DtkSpkMcVe90x6+QxxVqGuZCbE0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJ3lT94Y8nTfgQnwr+mGlphvXqnDg8hg2f/JrIjY0nHVB05Q CO5jgjxwhm06laRGxObTzc0JMdhzCrrP8da3D6fAo0l+q2VjSQaZDnsr/uH6EhMbCYiu3jw/ nJAIS5U6rjWOu4KZELlrX3+L4kbleI0y9dVGq7Sd2SFPUz2YOVptn+TiXs0xsXYqXv0X0fW+ Sr5/DKE7uMRdH4RnPQCMdvyHpI/BRpH7kAas9UOWpKItmnSzYbMn0vVU/yD2lMNTYTBFGG0L 53JjIiiNygx1v/Jx5s535zlaYo3ovGUV1NMU7lrQF6PBoybHhvcmN/8fs2cnBgbouMvIY/Ac CiEK4rAAAAAAAAA= --------------ms000809010701070002050805-- From andrjohn@cisco.com Thu Jun 18 01:10:36 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2283A6C1F for ; Thu, 18 Jun 2009 01:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jQfupOOJkq6 for ; Thu, 18 Jun 2009 01:10:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3FFB33A6B79 for ; Thu, 18 Jun 2009 01:10:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,243,1243814400"; d="scan'208";a="201820021" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-1.cisco.com with ESMTP; 18 Jun 2009 08:10:46 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5I8Ak2P029338; Thu, 18 Jun 2009 10:10:46 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5I8AjSH003132; Thu, 18 Jun 2009 08:10:45 GMT Received: from [10.55.163.39] (ams-andrjohn-8716.cisco.com [10.55.163.39]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n5I8AiY04210; Thu, 18 Jun 2009 09:10:44 +0100 (BST) Message-ID: <4A39F68D.4010001@cisco.com> Date: Thu, 18 Jun 2009 09:10:53 +0100 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <4A38F240.4000305@net.in.tum.de> <4A38F560.8020205@cisco.com> <4A39EEED.1050501@net.in.tum.de> In-Reply-To: <4A39EEED.1050501@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4994; t=1245312646; x=1246176646; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20Common=20structure=20for=20IPFIX-MIB=20 +=20IPFIX-CONFIG |Sender:=20; bh=1Cmbt2zmaNQbOKT2CadEpCTqYsQ35RN42SoMS7rGHy0=; b=VVXxmfN9Y2+m3sPjEXebpXeEQOO1XDHjTN2GCJ1wctXg7N4V52v5Q+1y1c eAfA6TCun6ElXu09coEEp6x2smSPUhXL+u5/A44mxc7XD6LO2PZiGLbXrv3z Z4ll/PYaUd; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 08:10:36 -0000 Hi Gerhard Gerhard Muenz wrote: > Hi Andrew, all, > > Andrew Johnson wrote: >> The definition of an Observation Domain is: >> An Observation Domain is the largest set of Observation Points for >> which Flow information can be aggregated by a Metering Process. >> >> By it's very definition a cache cannot monitor packets from different >> Observation Domains and configuring it should be impossible, not >> because of a limit of the configuration model, but because all >> Observation Points available to a cache are defined to be part of the >> same Observation Domain. > > Thanks for pointing this out. > > We define a Cache as part of one Monitoring Process. With the definition > of the Observation Domain, this excludes that packets of several ODs > enter the same Cache. I do not see any need to change this. > > Currently, there is no such restriction for Selection Sequences. > Am I right that PSAMP Selection Sequence Report Interpretation, > Selection Sequence Statistics Report, etc. are to be used regardless of > whether Packet Reports or Flow Records are generated by the Metering > Process? They could be sent if the user wished them to be. I guess it would be a configurable option. > If yes, packets that have been selected by different Selection Sequences > must not be aggregated in the same Flow Records. I don't see why not. If the user configured it so then they wouldn't gain the same benefit from the Selection Sequence Statistics, but that doesn't mean that they don't have a valid configuration. > The changes I proposed enforce that the input of a Cache is restricted > to packets originating from one OD and selected by one Selection Sequence. Surely you don't mean that. The cache should accept the input from as many Selection Sequences as the user wants. I can imagine why you thing forcing the SSID to be a key would be a good idea, but surely you don't mean you need a different cache for every Selection Sequence? Cheers Andrew > It is not possible (or would at least be very complicated) to achieve > the same restriction with the current config model using the YANG > formalism. We could only specify this in description clauses. > > With the proposed changes, invalid configurations are not possible by > specification of the config model. (of course, the YANG module can be > augmented if somebody really wants to do strange things) > > I would appreciate some more feedback on this. > > Regards, > Gerhard > > >> Gerhard Muenz wrote: >>> Benoit, Thomas, Paul, Andrew, Atsushi, >>> >>> I've been thinking a little bit more about the way how OPs, SPs, Caches, >>> and EPs are linked together in the MIB and in the config model. >>> >>> At the moment, the config model enables configurations in which a Cache >>> maintains records generated of packets observed at different >>> Observation Domains and/or selected by different Selection Processes. >>> >>> Example: >>> >>> OP1 -> SP1 -+ >>> +-> Cache -> EP >>> OP2 -> SP2 -+ >>> >>> However, packets of different OD or from different SPs MUST NOT be >>> accounted in the same record. Consequently, the Cache must implicitly >>> treat ODID and Selection Sequence ID as additional flow keys. >>> >>> Is this acceptable? >>> >>> Or should we inhibit such configurations and ensure by specification of >>> the config model that all packets entering a Cache come from the same OD >>> and have passed the identical Selection Processes? >>> >>> If the answer to the second question is yes, we can change the model as >>> follows: >>> >>> Instead of specifying where the output of an OP, SP, Cache goes,... >>> >>> OP -> SP -> Cache -> EP >>> >>> ...we specify where the input comes from: >>> >>> OP <- SP <- Cache <- EP >>> >>> This means that we invert the direction of the references. >>> >>> We can specify that SPs and Caches have a maximum of one input. This >>> ensures that packets entering the Cache come from a single SP, and >>> packets entering this SP come from a single OP. >>> >>> Instead of OP, we can adopt ObservationPointGroup (as used in the MIB) >>> to specify a group of OPs belonging to the same OD. >>> >>> Only for the EP, we allow multiple inputs from different Caches. >>> >>> Hence, configurations like this are possible: >>> >>> +- Cache1 <-+ >>> +- SP1 <-+ | >>> OPG <-+ +- Cache2 <-+- EP >>> | | >>> +- SP2 <--- Cache3 <-+ >>> >>> The disadvantage is that the linkage is done in the reverse direction of >>> the actual "data flow". >>> The advantage is that we can quite easily realize the same linkage in >>> the MIB using indexes. The changes in the MIB would be relatively small. >>> >>> If we decided to go this way, it should be done quickly such that we can >>> adapt the indexing in the MIB. >>> >>> Regards, >>> Gerhard >>> > From muenz@net.in.tum.de Thu Jun 18 01:24:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7333A6813 for ; Thu, 18 Jun 2009 01:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 knwFlwavQKRo for ; Thu, 18 Jun 2009 01:24:12 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id AF4603A6EF1 for ; Thu, 18 Jun 2009 01:23:56 -0700 (PDT) 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 8879C47BF2; Thu, 18 Jun 2009 10:23:51 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 7CAC25409; Thu, 18 Jun 2009 10:23:51 +0200 (CEST) Message-ID: <4A39F9EC.7080008@net.in.tum.de> Date: Thu, 18 Jun 2009 10:25:16 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Andrew Johnson References: <4A38F240.4000305@net.in.tum.de> <4A38F560.8020205@cisco.com> <4A39EEED.1050501@net.in.tum.de> <4A39F68D.4010001@cisco.com> In-Reply-To: <4A39F68D.4010001@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000100040509040108080406" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Common structure for IPFIX-MIB + IPFIX-CONFIG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 08:24:13 -0000 This is a cryptographically signed message in MIME format. --------------ms000100040509040108080406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Andrew, Andrew Johnson wrote: > Gerhard Muenz wrote: >> Andrew Johnson wrote: >>> The definition of an Observation Domain is: >>> An Observation Domain is the largest set of Observation Points for >>> which Flow information can be aggregated by a Metering Process. >>> >>> By it's very definition a cache cannot monitor packets from different >>> Observation Domains and configuring it should be impossible, not >>> because of a limit of the configuration model, but because all >>> Observation Points available to a cache are defined to be part of the >>> same Observation Domain. >> >> Thanks for pointing this out. >> >> We define a Cache as part of one Monitoring Process. With the definition >> of the Observation Domain, this excludes that packets of several ODs >> enter the same Cache. I do not see any need to change this. >> >> Currently, there is no such restriction for Selection Sequences. >> Am I right that PSAMP Selection Sequence Report Interpretation, >> Selection Sequence Statistics Report, etc. are to be used regardless of >> whether Packet Reports or Flow Records are generated by the Metering >> Process? > > They could be sent if the user wished them to be. I guess it would be > a configurable option. Yes, it is a configurable option. >> If yes, packets that have been selected by different Selection Sequences >> must not be aggregated in the same Flow Records. > > I don't see why not. If the user configured it so then they wouldn't > gain the same benefit from the Selection Sequence Statistics, but that > doesn't mean that they don't have a valid configuration. The reason is that counter values of mixed Flow Records are difficult to interpret. >> The changes I proposed enforce that the input of a Cache is restricted >> to packets originating from one OD and selected by one Selection >> Sequence. > > Surely you don't mean that. The cache should accept the input from as > many Selection Sequences as the user wants. I can imagine why you thing > forcing the SSID to be a key would be a good idea, but surely you don't > mean you need a different cache for every Selection Sequence? Actually, this was the plan to ensure that the counter values of the Flow Records can be interpreted correctly. If consensus is that we do not want to ensure this, then we only have to differentiate packets and caches with respect to the ODID. Gerhard >> It is not possible (or would at least be very complicated) to achieve >> the same restriction with the current config model using the YANG >> formalism. We could only specify this in description clauses. >> >> With the proposed changes, invalid configurations are not possible by >> specification of the config model. (of course, the YANG module can be >> augmented if somebody really wants to do strange things) >> >> I would appreciate some more feedback on this. >> >> Regards, >> Gerhard >> >> >>> Gerhard Muenz wrote: >>>> Benoit, Thomas, Paul, Andrew, Atsushi, >>>> >>>> I've been thinking a little bit more about the way how OPs, SPs, >>>> Caches, >>>> and EPs are linked together in the MIB and in the config model. >>>> >>>> At the moment, the config model enables configurations in which a Cache >>>> maintains records generated of packets observed at different >>>> Observation Domains and/or selected by different Selection Processes. >>>> >>>> Example: >>>> >>>> OP1 -> SP1 -+ >>>> +-> Cache -> EP >>>> OP2 -> SP2 -+ >>>> >>>> However, packets of different OD or from different SPs MUST NOT be >>>> accounted in the same record. Consequently, the Cache must implicitly >>>> treat ODID and Selection Sequence ID as additional flow keys. >>>> >>>> Is this acceptable? >>>> >>>> Or should we inhibit such configurations and ensure by specification of >>>> the config model that all packets entering a Cache come from the >>>> same OD >>>> and have passed the identical Selection Processes? >>>> >>>> If the answer to the second question is yes, we can change the model as >>>> follows: >>>> >>>> Instead of specifying where the output of an OP, SP, Cache goes,... >>>> >>>> OP -> SP -> Cache -> EP >>>> >>>> ...we specify where the input comes from: >>>> >>>> OP <- SP <- Cache <- EP >>>> >>>> This means that we invert the direction of the references. >>>> >>>> We can specify that SPs and Caches have a maximum of one input. This >>>> ensures that packets entering the Cache come from a single SP, and >>>> packets entering this SP come from a single OP. >>>> >>>> Instead of OP, we can adopt ObservationPointGroup (as used in the MIB) >>>> to specify a group of OPs belonging to the same OD. >>>> >>>> Only for the EP, we allow multiple inputs from different Caches. >>>> >>>> Hence, configurations like this are possible: >>>> >>>> +- Cache1 <-+ >>>> +- SP1 <-+ | >>>> OPG <-+ +- Cache2 <-+- EP >>>> | | >>>> +- SP2 <--- Cache3 <-+ >>>> >>>> The disadvantage is that the linkage is done in the reverse >>>> direction of >>>> the actual "data flow". >>>> The advantage is that we can quite easily realize the same linkage in >>>> the MIB using indexes. The changes in the MIB would be relatively >>>> small. >>>> >>>> If we decided to go this way, it should be done quickly such that we >>>> can >>>> adapt the indexing in the MIB. >>>> >>>> Regards, >>>> Gerhard --------------ms000100040509040108080406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE4MDgyNTE2WjAjBgkqhkiG9w0BCQQxFgQU bKvrie3aTyElhVIBTIL4iwrK9wQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABj1BZpun1vgvHNHJwr/RFwfSpOfQ8wCfzPlZmUAPtwHMJyW i5rZEf02B3Jmvw81B+sQH04VzDv28FHz2bb99J7ytVJ55c83GqGETl62l0xnKAgb7r1ALyit mqit1duftkDWxqlAK4XW1XS4wTaxvzqb76Y5FQXa5IlSZZ/GoU08bZAO1gGgvvMOBf//O0NX clhjzzEzK+Rp/H2ddIIJrDhAvHowOeR+Plkspt3OtDptDWtyC1KRZsFBK070ZJST6s/mzIqz Csw16Mk0kwchl044hhoYB37ZI9euUaR0IUmXSH0ee6HX9dIcxcZXfdasP+RSp8H96CtmHwF4 7dgMvJ4AAAAAAAA= --------------ms000100040509040108080406-- From akoba@nttv6.net Thu Jun 18 01:55:47 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDDB28C27C for ; Thu, 18 Jun 2009 01:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=1.233, 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 cy1G33fzcSWQ for ; Thu, 18 Jun 2009 01:55:46 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 4B6B53A6C98 for ; Thu, 18 Jun 2009 01:55:45 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ddd7:a3e4:df14:972c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5I8trGe073725 for ; Thu, 18 Jun 2009 17:55:53 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 18 Jun 2009 17:52:33 +0900 From: Atsushi Kobayashi To: IETF IPFIX Working Group Message-Id: <20090618161432.B5C8.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 18 Jun 2009 17:55:53 +0900 (JST) Subject: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 08:55:47 -0000 Hi Benoit, Gerhard, Brian, and all, In terminology section, there are main two discussion points. 1) the problem statement includes the more specific terms (IPFIX Concentrator, Proxy, Masq.Proxy, Distributor), or not? Brian, Gerhalz points out these terms seems restrict the work at framework, it is better the problem statement uses the more general terms. Benoit say it does not prefer that the discussion for the terminologies are postponed. I agree the Benoit. Although I can use the general terms in problem statement, using the terms enhances the images of the IPFIX mediation examples. So, I would like to keep these terms in problem statement. 2) the more specific terms (IPFIX Concentrator, Proxy, Masq.Proxy, Distributor) indicate the type of device, or a set of the functions. Gerhalz points out these terms are already perceived as type of devices, for example IPFIX Concentrator in RFC3917. Same questions arose from some NTT co-workers. Benoit say that the "device" implies a physical entity and restricts the future functions. I am worried that the terms become more complex meaning after thinking the future functions. I think that even if it is "device", it does not seem restrict the location in which the future functions applied. Because we can say that IPFIX Mediator does not implicitly require a separate physical entity. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that implements one or more IPFIX Mediation capabilities. Examples are devices such as routers, switches, network management systems (NMS), etc. Certainly, a IPFIX Mediator can have a set of the functions hosted in both IPFIX Proxy and IPFIX Concentrator. In that case, the Mediator can become IPFIX Proxy on one situation, and it can also become IPFIX Concentrator on other situations. Thus, I proposed here. IPFIX Proxy An IPFIX Proxy is a type of IPFIX Mediator that relays incoming Transport Sessions to one or multiple Collectors. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Thu Jun 18 01:59:57 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894F33A6973 for ; Thu, 18 Jun 2009 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 xI27iboMqutt for ; Thu, 18 Jun 2009 01:59:56 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 342473A6A5D for ; Thu, 18 Jun 2009 01:59:55 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ddd7:a3e4:df14:972c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5I905RK073757; Thu, 18 Jun 2009 18:00:05 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 18 Jun 2009 17:56:45 +0900 From: Atsushi Kobayashi To: Benoit Claise In-Reply-To: <4A38F1F4.5030706@cisco.com> References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> Message-Id: <20090618175305.B5CB.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 18 Jun 2009 18:00:05 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 08:59:57 -0000 Hi Benoit, and Gerhard, > >>> > >>>> maybe: > >>>> "...covers the manipulation of the content and transmission of Data > >>>> Records and IPFIX Messages." > >>>> > >>>> > >>> Fine. > >>> > >>> > >> Actually, I have a problem with this proposal, i.e. adding > >> "transmission" in the IPFIX Mediation definition. > >> > > > > Well, "transmission" was in the draft. It is not my wording. > > > Right. Sorry. > The draft version 3 says > > IPFIX Mediation > > IPFIX Mediation is a generic function that covers the manipulation > of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX > Messages, or their transmission. > > The proposal in this thread is: > > "...covers the manipulation of the content _and _transmission of Data > Records and IPFIX Messages." Do you mean "the transmission of Data Records _or_ IPFIX Messages" ? And we also put the (Options) Template Records. Finally, next version would say. "IPFIX Mediation is a function that covers the manipulation of the content and transmission of Data Records, (Options) Template Records, or IPFIX Messages. Here is a series of IPFIX Mediation examples: * content mediation that changes Data Records information + aggregating Data Records based on a new set of Flow Key fields > > The difference now is "and". This means that we always "transmit" in the > mediation > If "transmit" is perceived as "exported", then I have a problem > > "transmission" relates to the translation of Netflow into IPFIX etc. > > Do to this, I assume that an Intermediate Process is needed because the > > records need to be converted. In fact, the function can be quite complex. > > > > I'm open to better text covering such translations. Even "manipulation > > of Data Records" (in capital letters) is not precise because if we > > import from Netflow. Data Record is an IPFIX term. > > > > So, maybe just "manipulation and conversion of records"? > > > That makes more sense to me, and would be in line with the framework, > where the Exporting Process is a different process > > I agree. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Thu Jun 18 02:07:32 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CCFA3A6C9F for ; Thu, 18 Jun 2009 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 bY3ISVNpgHOS for ; Thu, 18 Jun 2009 02:07:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C23523A6C94 for ; Thu, 18 Jun 2009 02:07:30 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:ddd7:a3e4:df14:972c]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5I97foo073800; Thu, 18 Jun 2009 18:07:41 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 18 Jun 2009 18:04:21 +0900 From: Atsushi Kobayashi To: Atsushi Kobayashi In-Reply-To: <20090610211008.6E53.17391CF2@nttv6.net> References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> Message-Id: <20090618175929.B5CE.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 18 Jun 2009 18:07:41 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> Introduction X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:07:32 -0000 Hi Gerhard, and all, On Wed, 10 Jun 2009 21:39:41 +0900 Atsushi Kobayashi wrote: > > > 1. Introduction > > > > > > While the IPFIX requirements defined in [RFC3917] mention an > > > intermediate function, such as an IPFIX Proxy or an IPFIX > > > Concentrator, there are no documents defining the function called > > > IPFIX Mediation. IPFIX Mediation is a generic function that covers > > > the manipulation of IPFIX Flow Records, PSAMP Packet Reports, entire > > > IPFIX Messages, or their transmission. This document describes > > > general problems, applicability examples, and defines the terminology > > > (IPFIX Proxy, Concentrator, etc.) for referring to different use > > > cases for IPFIX Mediation. Furthermore, some specific problems > > > related to the IPFIX protocol [RFC5101] when applying IPFIX Mediation > > > are addressed. > > > > The only motivation for IPFIX Mediation given in this introduction is > > that the term has not yet defined in any document. This cannot be a > > reason for publishing an RFC ;) > > Yes, indeed. > > > > I would like to see a much stronger motivation elaborating the arguments > > and problems of the abstract. > > > > I will improve it. I would like to add the following paragraph in Introduction. 1. Introduction One advantage of Flow-based measurement results from easily offering the traffic monitoring of a huge amount of traffic. While the usage is applied to any networks and to multiple measurement applications, network administrators need to optimize the resource of metering devices and of multiple measurement applications. IP traffic growth and a wide variety of measurement application make it further difficult. To achieve system optimization, an intermediate device can generally be applied to the system platform. While the IPFIX requirements defined in [RFC3917] mention an intermediate device, such as an IPFIX Proxy or an IPFIX Concentrator, there are no documents defining the function called IPFIX Mediation. Regards, Atsushi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From trammell@tik.ee.ethz.ch Thu Jun 18 02:12:38 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193533A6C9F for ; Thu, 18 Jun 2009 02:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYTCz8dS6XoV for ; Thu, 18 Jun 2009 02:12:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id C334F3A687F for ; Thu, 18 Jun 2009 02:12:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 75037D9366; Thu, 18 Jun 2009 11:12:47 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WLpR6q2gcvSV; Thu, 18 Jun 2009 11:12:47 +0200 (MEST) Received: from [10.0.1.11] (77-58-83-74.dclient.hispeed.ch [77.58.83.74]) (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 1F80BD9364; Thu, 18 Jun 2009 11:12:47 +0200 (MEST) Message-Id: From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090618175929.B5CE.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 11:12:46 +0200 References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> <20090618175929.B5CE.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> Introduction X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:12:38 -0000 On Jun 18, 2009, at 11:04 AM, Atsushi Kobayashi wrote: > > Hi Gerhard, and all, > > On Wed, 10 Jun 2009 21:39:41 +0900 > Atsushi Kobayashi wrote: > >>>> 1. Introduction >>>> >>>> While the IPFIX requirements defined in [RFC3917] mention an >>>> intermediate function, such as an IPFIX Proxy or an IPFIX >>>> Concentrator, there are no documents defining the function called >>>> IPFIX Mediation. IPFIX Mediation is a generic function that >>>> covers >>>> the manipulation of IPFIX Flow Records, PSAMP Packet Reports, >>>> entire >>>> IPFIX Messages, or their transmission. This document describes >>>> general problems, applicability examples, and defines the >>>> terminology >>>> (IPFIX Proxy, Concentrator, etc.) for referring to different use >>>> cases for IPFIX Mediation. Furthermore, some specific problems >>>> related to the IPFIX protocol [RFC5101] when applying IPFIX >>>> Mediation >>>> are addressed. >>> >>> The only motivation for IPFIX Mediation given in this introduction >>> is >>> that the term has not yet defined in any document. This cannot be a >>> reason for publishing an RFC ;) >> >> Yes, indeed. >>> >>> I would like to see a much stronger motivation elaborating the >>> arguments >>> and problems of the abstract. >>> >> >> I will improve it. > > I would like to add the following paragraph in Introduction. > > 1. Introduction > > One advantage of Flow-based measurement results from easily offering > the traffic monitoring of a huge amount of traffic. While the usage > is applied to any networks and to multiple measurement applications, > network administrators need to optimize the resource of metering > devices and of multiple measurement applications. IP traffic growth > and a wide variety of measurement application make it further > difficult. To achieve system optimization, an intermediate device > can generally be applied to the system platform. > > While the IPFIX requirements defined in [RFC3917] mention an > intermediate device, such as an IPFIX Proxy or an IPFIX > Concentrator, > there are no documents defining the function called IPFIX Mediation. Consider replacing para two with an elaboration: The IPFIX requirements defined in [RFC3917] mention examples of intermediate devices, such as IPFIX Proxies or Concentrators, there are no documents defining a generalized concept for such intermediate devices. This document addresses that issue by defining IPFIX Mediation, a generalized intermediate device concept for IPFIX, and examining in detail the motivations behind its application. > > Regards, > Atsushi > > --- > 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 trammell@tik.ee.ethz.ch Thu Jun 18 02:15:26 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8015E3A6CA8 for ; Thu, 18 Jun 2009 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvABH5962fvW for ; Thu, 18 Jun 2009 02:15:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 27D8C3A6AE1 for ; Thu, 18 Jun 2009 02:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 006B0D9366; Thu, 18 Jun 2009 11:15:35 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5QDGajkw+U3M; Thu, 18 Jun 2009 11:15:35 +0200 (MEST) Received: from [10.0.1.11] (77-58-83-74.dclient.hispeed.ch [77.58.83.74]) (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 8EC9ED9364; Thu, 18 Jun 2009 11:15:35 +0200 (MEST) Message-Id: From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090618175305.B5CB.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 11:15:35 +0200 References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:15:26 -0000 On Jun 18, 2009, at 10:56 AM, Atsushi Kobayashi wrote: > > Hi Benoit, and Gerhard, > >>>>> >>>>>> maybe: >>>>>> "...covers the manipulation of the content and transmission of >>>>>> Data >>>>>> Records and IPFIX Messages." >>>>>> >>>>>> >>>>> Fine. >>>>> >>>>> >>>> Actually, I have a problem with this proposal, i.e. adding >>>> "transmission" in the IPFIX Mediation definition. >>>> >>> >>> Well, "transmission" was in the draft. It is not my wording. >>> >> Right. Sorry. >> The draft version 3 says >> >> IPFIX Mediation >> >> IPFIX Mediation is a generic function that covers the >> manipulation >> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >> Messages, or their transmission. >> >> The proposal in this thread is: >> >> "...covers the manipulation of the content _and _transmission of Data >> Records and IPFIX Messages." > > Do you mean "the transmission of Data Records _or_ IPFIX Messages" ? > And we also put the (Options) Template Records. > > Finally, next version would say. > > "IPFIX Mediation is a function that covers the manipulation of the > content and transmission of Data Records, (Options) Template > Records, or > IPFIX Messages. Here is a series of IPFIX Mediation examples: > > * content mediation that changes Data Records information > > + aggregating Data Records based on a new set of Flow Key > fields If we _must_. I actually prefer to keep examples out of terminology (it still looks like it is intended as a covering set) and to define _functions_. You have the rest of the document (and indeed, do use it) to talk about the examples. Again, where we do speak specifically, I think we want to talk explicitly in terms of defined intermediate processes (e.g., Intermediate Aggregation Process, Intermediate Selection Process, and so on), and not try to wedge a covering set of mediation functions into a definition "IPFIX Mediation" that isn't really used anywhere (i.e., the _document_ talks about IPFIX Mediation, but all of the terms to which specifications can be meaningfully applied -- devices, processes functions -- are at a lower level...) >> The difference now is "and". This means that we always "transmit" >> in the >> mediation >> If "transmit" is perceived as "exported", then I have a problem >>> "transmission" relates to the translation of Netflow into IPFIX etc. >>> Do to this, I assume that an Intermediate Process is needed >>> because the >>> records need to be converted. In fact, the function can be quite >>> complex. >>> >>> I'm open to better text covering such translations. Even >>> "manipulation >>> of Data Records" (in capital letters) is not precise because if we >>> import from Netflow. Data Record is an IPFIX term. >>> >>> So, maybe just "manipulation and conversion of records"? >>> >> That makes more sense to me, and would be in line with the framework, >> where the Exporting Process is a different process >>> > > I agree. > > Regards, > Atsushi > > --- > 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 nishida.haruhiko@lab.ntt.co.jp Thu Jun 18 03:17:51 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E243A68CF for ; Thu, 18 Jun 2009 03:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2f72qVKA74l for ; Thu, 18 Jun 2009 03:17:51 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id E2D323A6896 for ; Thu, 18 Jun 2009 03:17:50 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n5IAI2UL007163; Thu, 18 Jun 2009 19:18:02 +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 471F96ACA; Thu, 18 Jun 2009 19:18:02 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 3D868693A; Thu, 18 Jun 2009 19:18:02 +0900 (JST) Received: from [129.60.149.196] ([129.60.149.196]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id n5IAI1jV016253; Thu, 18 Jun 2009 19:18:01 +0900 (JST) Message-Id: <5D5E4D31-8389-4385-8350-EE542FF00380@lab.ntt.co.jp> From: Nishida Haruhiko To: Brian Trammell In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 19:18:01 +0900 References: <4A1BE50E.6040407@net.in.tum.de> <20090610211008.6E53.17391CF2@nttv6.net> <20090618175929.B5CE.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> Introduction X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 10:17:51 -0000 Brian, I love your para two. The original (problem-statement-03) "there are no documents defining the function called IPFIX Mediation" is true, but not too make sense. -- Haru Nishida, NTT On 2009/06/18, at 18:12, Brian Trammell wrote: > Consider replacing para two with an elaboration: > > The IPFIX requirements defined in [RFC3917] mention examples of > intermediate devices, such as IPFIX Proxies or Concentrators, > there are no documents defining a generalized concept for such > intermediate devices. This document addresses that issue by defining > IPFIX Mediation, a generalized intermediate device concept for IPFIX, > and examining in detail the motivations behind its application. From Quittek@nw.neclab.eu Thu Jun 18 07:26:04 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F417B28C347; Thu, 18 Jun 2009 07:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041] 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 BsQGJCRO1gM1; Thu, 18 Jun 2009 07:26:02 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D520528C340; Thu, 18 Jun 2009 07:26:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 088FE2C01C8EC; Thu, 18 Jun 2009 16:26:14 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbWNC3oOGTaz; Thu, 18 Jun 2009 16:26:13 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id B2C9B2C019196; Thu, 18 Jun 2009 16:25:53 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Jun 2009 14:25:53 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3328187171_2922100" Date: Thu, 18 Jun 2009 16:26:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter Thread-Index: AcnvgNcTDmN0YTA0zUKyt9t4T6yGqAACap7AACWNtoM= From: "Juergen Quittek" To: "Dan Romascanu" Cc: IETF PSAMP Working Group , Nevil Brownlee , IETF IPFIX Working Group Subject: Re: [IPFIX] Concluding the PSAM WG and moving the remaining work item to the IPFIX WG charter X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 14:26:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328187171_2922100 Content-type: multipart/mixed; boundary="B_3328187171_2912016" --B_3328187171_2912016 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dan, Please find attached an updated charter with adjusted milestones. I also attached a diff between the current and the proposed new charter. Thanks, Juergen On 17.06.09 22:42 "Dan Romascanu" wrote: > This is fine and I support the move. > > Can you please forward me a revised IPFIX charter with the PSAMP MIB > added? > > It would be a good opportunity to adjust milestones if necessary. > > Dan --B_3328187171_2912016 Content-type: text/plain; name="ipfix-charter-new.txt"; x-mac-creator="522A6368"; x-mac-type="54455854" Content-disposition: attachment; filename="ipfix-charter-new.txt" Content-transfer-encoding: base64 SVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKGlwZml4KQoKTGFzdCBNb2RpZmllZDogMjAw OS0wMy0xMAoKQWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcvd2cvaXBmaXgKCkNoYWlyKHMpOgoKIyBOZXZpbCBCcm93bmxlZSA8bi5icm93 bmxlZUBhdWNrbGFuZC5hYy5uej4KIyBKdWVyZ2VuIFF1aXR0ZWsgPHF1aXR0ZWtAbmV0bGFi Lm5lYy5kZT4KCk9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQgQXJlYSBEaXJlY3RvcihzKToK CiMgRGFuIFJvbWFzY2FudSA8ZHJvbWFzY2FAYXZheWEuY29tPgojIFJvbmFsZCBCb25pY2Eg PHJib25pY2FAanVuaXBlci5uZXQ+CgpPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50IEFyZWEg QWR2aXNvcjoKCiMgRGFuIFJvbWFzY2FudSA8ZHJvbWFzY2FAYXZheWEuY29tPgoKTWFpbGlu ZyBMaXN0czoKCkdlbmVyYWwgRGlzY3Vzc2lvbjogaXBmaXhAaWV0Zi5vcmcKVG8gU3Vic2Ny aWJlOiBodHRwOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgKQXJjaGl2 ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwZml4CgpEZXNjcmlw dGlvbiBvZiBXb3JraW5nIEdyb3VwOgoKVGhlIElQRklYIHdvcmtpbmcgZ3JvdXAgaGFzIHNw ZWNpZmllZCB0aGUgSW5mb3JtYXRpb24gTW9kZWwgKHRvCmRlc2NyaWJlIElQIGZsb3dzKSBh bmQgdGhlIElQRklYIHByb3RvY29sICh0byB0cmFuc2ZlciBJUCBmbG93IGRhdGEKZnJvbSBJ UEZJWCBleHBvcnRlcnMgdG8gY29sbGVjdG9ycykuIFNldmVyYWwgaW1wbGVtZW50ZXJzIGhh dmUgYWxyZWFkeQpidWlsdCBhcHBsaWNhdGlvbnMgdXNpbmcgdGhlIElQRklYIHByb3RvY29s LiBBcyBhIHJlc3VsdCBvZiBhIHNlcmllcwpvZiBJUEZJWCBpbnRlcm9wZXJhYmlsaXR5IHRl c3RpbmcgZXZlbnRzIHRoZSBXRyBoYXMgcHJvZHVjZWQKZ3VpZGVsaW5lcyBmb3IgSVBGSVgg aW1wbGVtZW50YXRpb24gYW5kIHRlc3RpbmcgYXMgd2VsbCBhcwpyZWNvbW1lbmRhdGlvbnMg Zm9yIGhhbmRsaW5nIHNwZWNpYWwgY2FzZXMgc3VjaCBhcyBiaWRpcmVjdGlvbmFsIGZsb3cK cmVwb3J0aW5nIGFuZCByZWR1Y2luZyByZWR1bmRhbmN5IGluIGZsb3cgcmVjb3Jkcy4KClBy YWN0aWNhbCBleHBlcmllbmNlcyB3aXRoIElQRklYIGltcGxlbWVudGF0aW9ucyBleHBvc2Vk IG5ldwpyZXF1aXJlbWVudHMgZm9yIHRoZSBJUEZJWCBwcm90b2NvbCB0aGF0IHNvIGZhciBo YXZlIG5vdCBiZWVuCmFkZHJlc3NlZCBieSB0aGUgV0cuIFRoZSBtYWpvciBjdXJyZW50IGdv YWwgb2YgdGhlIFdHIGlzIGRldmVsb3BpbmcKc29sdXRpb25zIHRoYXQgbWVldCB0aGUgbmV3 IHJlcXVpcmVtZW50cyB3aXRob3V0IG1vZGlmeWluZyB0aGUgY29yZQpJUEZJWCBwcm90b2Nv bCBzcGVjaWZpY2F0aW9ucy4KCjEuIFRoZSBJUEZJWCBXRyBoYXMgZGV2ZWxvcGVkIGEgTUlC IG1vZHVsZSBmb3IgbW9uaXRvcmluZyBJUEZJWAppbXBsZW1lbnRhdGlvbnMuIE1lYW5zIGZv ciBjb25maWd1cmluZyB0aGVzZSBkZXZpY2VzIGhhdmUgbm90IGJlZW4Kc3RhbmRhcmRpemVk IHlldC4gVGhlIFdHIHdpbGwgZGV2ZWxvcCBhbiBYTUwtYmFzZWQgY29uZmlndXJhdGlvbiBk YXRhCm1vZGVsIHRoYXQgY2FuIGJlIHVzZWQgZm9yIGNvbmZpZ3VyaW5nIElQRklYIGRldmlj ZXMgYW5kIGZvciBzdG9yaW5nLAptb2RpZnlpbmcgYW5kIG1hbmFnaW5nIElQRklYIGNvbmZp Z3VyYXRpb25zIHBhcmFtZXRlciBzZXRzLiBUaGlzIHdvcmsKd2lsbCBiZSBwZXJmb3JtZWQg aW4gY2xvc2UgY29sbGFib3JhdGlvbiB3aXRoIHRoZSBORVRDT05GIFdHLgoKMi4gVGhlcmUg aXMgYSBuZWVkIGZvciBzdG9yaW5nIG1lYXN1cmVkIGZsb3cgaW5mb3JtYXRpb24gYW5kIGZv cgpleGNoYW5naW5nIHRoaXMgaW5mb3JtYXRpb24gYmV0d2VlbiBkaWZmZXJlbnQgc3lzdGVt cyBhbmQKb3JnYW5pemF0aW9ucy4gVGhlIFdHIHdpbGwgZGV2ZWxvcCBhIGNvbW1vbiBJUEZJ WCBmaWxlIGZvcm1hdCBmb3IKc3RvcmluZyBmbG93IGRhdGEgaW4gb3JkZXIgdG8gZmFjaWxp dGF0ZSBpbnRlcm9wZXJhYmlsaXR5IGFuZApyZXVzYWJpbGl0eSBhbW9uZyBhIHdpZGUgdmFy aWV0eSBvZiBmbG93IHN0b3JhZ2UsIHByb2Nlc3NpbmcsIGFuZAphbmFseXNpcyB0b29scy4g SXQgd2lsbCBiZSBhIGZsYXQtZmlsZSBmb3JtYXQgdXNpbmcgYmluYXJ5IGVuY29kaW5ncwp0 aGF0IGFyZSBiYXNlZCBvbiB0aGUgSVBGSVggbWVzc2FnZSBmb3JtYXQuCgozLiBXaGVuIGRl YWxpbmcgd2l0aCBlbnRlcnByaXNlLXNwZWNpZmljIGluZm9ybWF0aW9uIGVsZW1lbnRzIGlu IElQRklYCmZsb3cgcmVjb3JkcywgaXQgb2Z0ZW4gb2NjdXJzIHRoYXQgdGhlIHJlY2VpdmVy IG9mIHRoZSByZWNvcmQgZG9lcyBub3QKa25vdyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgaW5m b3JtYXRpb24gZWxlbWVudC4gRm9yIHByb2Nlc3Npbmcgc3VjaAppbmZvcm1hdGlvbiBlbGVt ZW50cyBpdCB3b3VsZCBiZSBkZXNpcmFibGUgZm9yIHRoZSByZWNlaXZlciB0byBrbm93IGF0 CmxlYXN0IHRoZSBkYXRhIHR5cGVzIG9mIHRoZSBlbnRlcnByaXNlLXNwZWNpZmljIGluZm9y bWF0aW9uIGVsZW1lbnRzLgpUaGUgV0cgd2lsbCBkZXZlbG9wIGFuIGV4dGVuc2lvbiB0byBJ UEZJWCB0aGF0IHByb3ZpZGVzIG1lYW5zIGZvciB0aGUKZW5jb2Rpbmcgb2YgSVBGSVggZGF0 YSB0eXBlIGluZm9ybWF0aW9uIHdpdGhpbiBhbiBJUEZJWCBNZXNzYWdlCnN0cmVhbS4KCjQu IEFub3RoZXIgcmVxdWlyZW1lbnQgcmVzdWx0aW5nIGZyb20gcHJhY3RpY2FsIHVzZSBvZiBJ UEZJWCBpcwpyZXBvcnRpbmcgSVBGSVggdGVtcGxhdGUgcmVjb3JkcyBhbmQgY29ycmVzcG9u ZGluZyBkYXRhIHJlY29yZHMgd2l0aGluCnRoZSBzYW1lIFNDVFAgc3RyZWFtLiBUaGUgSVBG SVggV0cgd2lsbCBkZXZlbG9wIGd1aWRlbGluZXMgZm9yIHRoaXMKdXNlIGNhc2UuCgo1LiBG aXJzdCBhcHBsaWNhdGlvbnMgb2YgSVBGSVggYXQgbGFyZ2Ugb3BlcmF0b3IgbmV0d29ya3Mg c2hvd2VkIHRoZQpuZWVkIGZvciBtZWRpYXRpb24gb2YgZmxvdyBpbmZvcm1hdGlvbiwgZm9y IGV4YW1wbGUsIGZvciBhZ2dyZWdhdGluZwpodWdlIGFtb3VudHMgb2YgZmxvdyBkYXRhIGFu ZCBmb3IgYW5vbXltaXphdGlvbiBvZiBmbG93IGluZm9ybWF0aW9uLgpUaGUgSVBGSVggV0cg d2lsbCBpbnZlc3RpZ2F0ZSB0aGlzIGlzc3VlIGFuZCBwcm9kdWNlIGEgcHJvYmxlbQpzdGF0 ZW1lbnQgYW5kIGEgZnJhbWV3b3JrIGZvciBJUEZJWCBmbG93IG1lZGlhdGlvbi4KCjYuIFRo ZSBQU0FNUCBXRyBoYXMgZGV2ZWxvcGVkIGEgcHJvdG9jb2wgZm9yIHJlcG9ydGluZwpvYnNl cnZlZCBwYWNrZXRzLiBUaGUgUFNBTVAgcHJvdG9jb2wgaXMgYW4gZXh0ZW5zaW9uIG9mCnRo ZSBJUEZJWCBwcm90b2NvbC4gVGhlIElQRklYIFdHIHdpbGwgZGV2ZWxvcCBhIE1JQiBtb2R1 bGUKZm9yIG1vbml0b3JpbmcgUFNBTVAgaW1wbGVtZW50YXRpb25zLiBUaGUgbmV3IE1JQiBt b2R1bGUKd2lsbCBiZSBhbiBleHRlbnNpb24gb2YgdGhlIElQRklYIE1JQiBtb2R1bGUuCgpH b2FscyBhbmQgTWlsZXN0b25lczoKCkRvbmUJICAJU3VibWl0IFJldmlzZWQgSW50ZXJuZXQt RHJhZnQgb24gSVAgRmxvdyBFeHBvcnQgUmVxdWlyZW1lbnRzCkRvbmUJICAJU3VibWl0IElu dGVybmV0LURyYWZ0IG9uIElQIEZsb3cgRXhwb3J0IEFyY2hpdGVjdHVyZQpEb25lCSAgCVN1 Ym1pdCBJbnRlcm5ldC1EcmFmdCBvbiBJUCBGbG93IEV4cG9ydCBEYXRhIE1vZGVsCkRvbmUJ ICAJU3VibWl0IEludGVybmV0LURyYWZ0IG9uIElQRklYIFByb3RvY29sIEV2YWx1YXRpb24g UmVwb3J0CkRvbmUJICAJU3VibWl0IEludGVybmV0LURyYWZ0IG9uIElQIEZsb3cgRXhwb3J0 IEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50CkRvbmUJICAJU2VsZWN0IElQRklYIHByb3RvY29s LCByZXZpc2UgQXJjaGl0ZWN0dXJlIGFuZCBEYXRhIE1vZGVsIGRyYWZ0cwpEb25lCSAgCVN1 Ym1pdCBJUEZYLVJFUVVJUkVNRU5UUyB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZv cm1hdGlvbmFsIFJGQwpEb25lCSAgCVN1Ym1pdCBJUEZJWCBQcm90b2NvbCBFdmFsdWF0aW9u IFJlcG9ydCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsIFJGQwpE b25lCSAgCVN1Ym1pdCBJUEZYLUFSQ0hJVEVDVFVSRSB0byBJRVNHIGZvciBwdWJsaWNhdGlv biBhcyBQcm9wb3NlZCBTdGFuZGFyZCBSRkMKRG9uZQkgIAlTdWJtaXQgSVBGWC1JTkZPX01P REVMIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDCkRvbmUJ ICAJU3VibWl0IElQRlgtQVBQTElDQUJJTElUWSB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBh cyBJbmZvcm1hdGlvbmFsIFJGQwpEb25lCSAgCVN1Ym1pdCBJUEZYLVBST1RPQ09MIHRvIElF U0cgZm9yIHB1YmxpY2F0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkIFJGQwpEb25lCSAgCVB1 Ymxpc2ggSW50ZXJuZXQgRHJhZnQgb24gSVBGSVggSW1wbGVtZW50YXRpb24gR3VpZGVsaW5l cwpEb25lCSAgCVB1Ymxpc2ggSW50ZXJuZXQgRHJhZnQgb24gUmVkdWNpbmcgUmVkdW5kYW5j eSBpbiBJUEZJWCBkYXRhIHRyYW5zZmVyCkRvbmUJICAJUHVibGlzaCBJbnRlcm5ldCBEcmFm dCBvbiBIYW5kbGluZyBJUEZJWCBCaWRpcmVjdGlvbmFsIEZsb3dzCkRvbmUJICAJUHVibGlz aCBJbnRlcm5ldCBEcmFmdCBvbiBJUEZJWCBUZXN0aW5nCkRvbmUJICAJUHVibGlzaCBJbnRl cm5ldCBEcmFmdCBvbiBJUEZJWCBNSUIKRG9uZQkgIAlTdWJtaXQgSVBGSVggSW1wbGVtZW50 YXRpb24gR3VpZGVsaW5lcyBkcmFmdCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZv cm1hdGlvbmFsIFJGQwpEb25lCSAgCVN1Ym1pdCBJUEZJWCBSZWR1Y2luZyBSZWR1bmRhbmN5 IGRyYWZ0IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDCkRv bmUJICAJU3VibWl0IElQRklYIFRlc3RpbmcgZHJhZnQgdG8gSUVTRyBmb3IgcHVibGljYXRp b24gYXMgSW5mb3JtYXRpb25hbCBSRkMKRG9uZQkgIAlTdWJtaXQgSVBGSVggQmlmbG93cyBk cmFmdCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBTdGFuZGFyZHMgVHJhY2sgUkZDCkRv bmUJICAJUHVibGlzaCBJbnRlcm5ldCBkcmFmdCBvbiBJUEZJWCBUeXBlIEluZm9ybWF0aW9u IEV4cG9ydApEb25lCSAgCVB1Ymxpc2ggSW50ZXJuZXQgZHJhZnQgb24gSVBGSVggRmlsZSBG b3JtYXQKRG9uZQkgIAlQdWJsaXNoIEludGVybmV0IGRyYWZ0IG9uIElQRklYIENvbmZpZ3Vy YXRpb24gRGF0YSBNb2RlbApEb25lCSAgCVB1Ymxpc2ggSW50ZXJuZXQgZHJhZnQgb24gU2lu Z2xlIFNDVFAgU3RyZWFtIFJlcG9ydGluZwpEb25lCSAgCVN1Ym1pdCBGaWxlIEZvcm1hdCBk cmFmdCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBTdGFuZGFyZHMgdHJhY2sgUkZDCkRv bmUJICAJUHVibGlzaCBJbnRlcm5ldCBkcmFmdCBvbiBJUEZJWCBNZWRpYXRpb24gUHJvYmxl bSBTdGF0ZW1lbnQKRG9uZQkgIAlTdWJtaXQgSVBGSVggTUlCIGRyYWZ0IHRvIElFU0cgZm9y IHB1YmxpY2F0aW9uIGFzIFN0YW5kYXJkcyB0cmFjayBSRkMKRG9uZQkgIAlTdWJtaXQgVHlw ZSBFeHBvcnQgZHJhZnQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgU3RhbmRhcmRzIHRy YWNrIFJGQwpEb25lCSAgCVN1Ym1pdCBTaW5nbGUgU0NUUCBTdHJlYW0gZHJhZnQgdG8gSUVT RyBmb3IgcHVibGljYXRpb24gYXMgSW5mb3JtYXRpb25hbCBSRkMKU2VwIDIwMDkJICAJU3Vi bWl0IENvbmZpZ3VyYXRpb24gRGF0YSBNb2RlbCBkcmFmdCB0byBJRVNHIGZvciBwdWJsaWNh dGlvbiBhcyBTdGFuZGFyZHMgdHJhY2sgUkZDCkp1bCAyMDA5CSAgCVN1Ym1pdCBNZWRpYXRp b24gUHJvYmxlbSBTdGF0ZW1lbnQgSS1EIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIElu Zm9ybWF0aW9uYWwgUkZDClNlcCAyMDA5CSAgCVN1Ym1pdCBNZWRpYXRpb24gRnJhbWV3b3Jr IEktRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsIFJGQyAKSmFu IDIwMTAJICAJU3VibWl0IGZpbmFsIHZlcnNpb24gb2YgUFNBTVAgTUlCIG1vZHVsZQ== --B_3328187171_2912016 Content-type: text/plain; name="ipfix-charter-diff.txt"; x-mac-type="54455854" Content-disposition: attachment; filename="ipfix-charter-diff.txt" Content-transfer-encoding: base64 NzlhODAsODUKPiA2LiBUaGUgUFNBTVAgV0cgaGFzIGRldmVsb3BlZCBhIHByb3RvY29sIGZv ciByZXBvcnRpbmcKPiBvYnNlcnZlZCBwYWNrZXRzLiBUaGUgUFNBTVAgcHJvdG9jb2wgaXMg YW4gZXh0ZW5zaW9uIG9mCj4gdGhlIElQRklYIHByb3RvY29sLiBUaGUgSVBGSVggV0cgd2ls bCBkZXZlbG9wIGEgTUlCIG1vZHVsZQo+IGZvciBtb25pdG9yaW5nIFBTQU1QIGltcGxlbWVu dGF0aW9ucy4gVGhlIG5ldyBNSUIgbW9kdWxlCj4gd2lsbCBiZSBhbiBleHRlbnNpb24gb2Yg dGhlIElQRklYIE1JQiBtb2R1bGUuCj4gCjExMSwxMTRjMTE3LDEyMQo8IEphbiAyMDA5CSAg CVN1Ym1pdCBTaW5nbGUgU0NUUCBTdHJlYW0gZHJhZnQgdG8gSUVTRyBmb3IgcHVibGljYXRp b24gYXMgSW5mb3JtYXRpb25hbCBSRkMKPCBNYXIgMjAwOQkgIAlTdWJtaXQgQ29uZmlndXJh dGlvbiBEYXRhIE1vZGVsIGRyYWZ0IHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uIGFzIFN0YW5k YXJkcyB0cmFjayBSRkMKPCBBcHIgMjAwOQkgIAlTdWJtaXQgTWVkaWF0aW9uIFByb2JsZW0g U3RhdGVtZW50IEktRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFs IFJGQwo8IEp1biAyMDA5CSAgCVN1Ym1pdCBNZWRpYXRpb24gRnJhbWV3b3JrIEktRCB0byBJ RVNHIGZvciBwdWJsaWNhdGlvbiBhcyBJbmZvcm1hdGlvbmFsIFJGQyAKLS0tCj4gRG9uZQkg IAlTdWJtaXQgU2luZ2xlIFNDVFAgU3RyZWFtIGRyYWZ0IHRvIElFU0cgZm9yIHB1YmxpY2F0 aW9uIGFzIEluZm9ybWF0aW9uYWwgUkZDCj4gU2VwIDIwMDkJICAJU3VibWl0IENvbmZpZ3Vy YXRpb24gRGF0YSBNb2RlbCBkcmFmdCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbiBhcyBTdGFu ZGFyZHMgdHJhY2sgUkZDCj4gSnVsIDIwMDkJICAJU3VibWl0IE1lZGlhdGlvbiBQcm9ibGVt IFN0YXRlbWVudCBJLUQgdG8gSUVTRyBmb3IgcHVibGljYXRpb24gYXMgSW5mb3JtYXRpb25h bCBSRkMKPiBTZXAgMjAwOQkgIAlTdWJtaXQgTWVkaWF0aW9uIEZyYW1ld29yayBJLUQgdG8g SUVTRyBmb3IgcHVibGljYXRpb24gYXMgSW5mb3JtYXRpb25hbCBSRkMgCj4gSmFuIDIwMTAJ ICAJU3VibWl0IGZpbmFsIHZlcnNpb24gb2YgUFNBTVAgTUlCIG1vZHVsZQo= --B_3328187171_2912016-- --B_3328187171_2922100 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename = "smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRcMlWWZhUr3mB1ayLV 2bkR2cT1bDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTgxNDI2MTFaMA0GCSqGSIb3DQEBAQUABIIBAI+XgKidR29i0o3YDFoJZMeWtMnYCFYha44O 2qT0qdSLvtI9YbjIcIByzchq4KfPKVKYK2xN/GCsss+zic1/NlMGltTbu025bM9AYPP/A5t9 pMURP3ghPp8uN0mCffkvRac4HvVIG/Q/Rm44MTiSHnac51dL8jwDeUEmn4wRj8ct2907i3XW O+UoW7xiKKRKp7Mapy1KX9DhbBK29/yy9PqMUUIlvDUp5ejiRYdgo08uFnbz206IJf9K5w6O yM7hG3uz9Ot0rgXA1R2nedMQNvnGveNmFG6cmoISLfTeBp0/KTc8vR8Sp19anEpdjg4N3aIz S1k1ZT9J0yRkRHblxMw= --B_3328187171_2922100-- From muenz@net.in.tum.de Fri Jun 19 01:19:07 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156393A67F0 for ; Fri, 19 Jun 2009 01:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 AH2eMRixH3kC for ; Fri, 19 Jun 2009 01:19:06 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 4116D3A679C for ; Fri, 19 Jun 2009 01:19:02 -0700 (PDT) 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 877AC48308; Fri, 19 Jun 2009 10:18:57 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 74768502B; Fri, 19 Jun 2009 10:18:57 +0200 (CEST) Message-ID: <4A3B4A46.1060503@net.in.tum.de> Date: Fri, 19 Jun 2009 10:20:22 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090618161432.B5C8.17391CF2@nttv6.net> In-Reply-To: <20090618161432.B5C8.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080105060003080108070600" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:19:07 -0000 This is a cryptographically signed message in MIME format. --------------ms080105060003080108070600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Atsushi, Atsushi Kobayashi wrote: > Hi Benoit, Gerhard, Brian, and all, > > In terminology section, there are main two discussion points. > > 1) the problem statement includes the more specific terms (IPFIX > Concentrator, Proxy, Masq.Proxy, Distributor), or not? > > Brian, Gerhalz points out these terms seems restrict the work at framework, > it is better the problem statement uses the more general terms. Benoit > say it does not prefer that the discussion for the terminologies are > postponed. > > I agree the Benoit. Although I can use the general terms in problem > statement, using the terms enhances the images of the IPFIX mediation > examples. > > So, I would like to keep these terms in problem statement. > > 2) the more specific terms (IPFIX Concentrator, Proxy, Masq.Proxy, > Distributor) indicate the type of device, or a set of the functions. > > Gerhalz points out these terms are already perceived as type of > devices, for example IPFIX Concentrator in RFC3917. > Same questions arose from some NTT co-workers. Benoit say that the > "device" implies a physical entity and restricts the future functions. > > I am worried that the terms become more complex meaning after thinking > the future functions. I think that even if it is "device", it does not seem > restrict the location in which the future functions applied. > > Because we can say that IPFIX Mediator does not implicitly require a > separate physical entity. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. > > Certainly, a IPFIX Mediator can have a set of the functions hosted in > both IPFIX Proxy and IPFIX Concentrator. In that case, the Mediator > can become IPFIX Proxy on one situation, and it can also become IPFIX > Concentrator on other situations. > > Thus, I proposed here. > > IPFIX Proxy > > An IPFIX Proxy is a type of IPFIX Mediator that relays incoming > Transport Sessions to one or multiple Collectors. This approach is ok for me. So, IPFIX Concentrator|Proxy|... describe specific flavors of IPFIX Mediator devices. Gerhard > Regards, > Atsushi --------------ms080105060003080108070600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE5MDgyMDIyWjAjBgkqhkiG9w0BCQQxFgQU hXxTZ4REU56xyqgB0pKT15LRWX8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBABeVG/flk/s8KR0rD7QCthJZZTj25oMlbI5Ik4uQP0IImzoT zBqkVDScXWhH1I2jxognPjby76+2vdzE1MacYG47W9Ky4fsosb3QV08GsdI3iaHJ87b/YHwv ROZhOL5Xliai+nptwdFUnDhgXsFBy83lw/xOWjelLfuG6na/rDxHz6Z06fXTTlu9Zw41YvZ/ fA/j1lQqjgrl+pTgw5PZYvdgNPMzRJFY4Xs9kJ7CsKlBLSPnm6z0P6C7Nt4aee3dJ3iTHl7V iswbJYX4hpYZiF9GTRlE+EfLo97eopsO4m/s4vnvBszoLnhj3CDmTTaU82JUTun6o/rnMDQU xVpzK+YAAAAAAAA= --------------ms080105060003080108070600-- From muenz@net.in.tum.de Fri Jun 19 01:26:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E773A6812 for ; Fri, 19 Jun 2009 01:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRqkKQ+n9Vmx for ; Fri, 19 Jun 2009 01:26:16 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id CA0243A67F5 for ; Fri, 19 Jun 2009 01:26:15 -0700 (PDT) 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 4B65247BF2; Fri, 19 Jun 2009 10:26:17 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 278F95409; Fri, 19 Jun 2009 10:26:17 +0200 (CEST) Message-ID: <4A3B4BFE.5040604@net.in.tum.de> Date: Fri, 19 Jun 2009 10:27:42 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> In-Reply-To: <20090618175305.B5CB.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090600040302020204070707" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:26:17 -0000 This is a cryptographically signed message in MIME format. --------------ms090600040302020204070707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Hi Benoit, and Gerhard, >=20 >>>>> =20 >>>>>> maybe: >>>>>> "...covers the manipulation of the content and transmission of Dat= a >>>>>> Records and IPFIX Messages." >>>>>> =20 >>>>>> =20 >>>>> Fine. >>>>> =20 >>>>> =20 >>>> Actually, I have a problem with this proposal, i.e. adding >>>> "transmission" in the IPFIX Mediation definition. >>>> =20 >>> Well, "transmission" was in the draft. It is not my wording. >>> =20 >> Right. Sorry. >> The draft version 3 says >> >> IPFIX Mediation >> >> IPFIX Mediation is a generic function that covers the manipulati= on >> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >> Messages, or their transmission. >> >> The proposal in this thread is: >> >> "...covers the manipulation of the content _and _transmission of Data >> Records and IPFIX Messages." >=20 > Do you mean "the transmission of Data Records _or_ IPFIX Messages" ?=20 > And we also put the (Options) Template Records. >=20 > Finally, next version would say. >=20 > "IPFIX Mediation is a function that covers the manipulation of the > content and transmission of Data Records, (Options) Template Records, o= r > IPFIX Messages. Here is a series of IPFIX Mediation examples: >=20 > * content mediation that changes Data Records information >=20 > + aggregating Data Records based on a new set of Flow Key > fields Hm, no, see below. >> The difference now is "and". This means that we always "transmit" in t= he=20 >> mediation >> If "transmit" is perceived as "exported", then I have a problem >>> "transmission" relates to the translation of Netflow into IPFIX etc. >>> Do to this, I assume that an Intermediate Process is needed because t= he >>> records need to be converted. In fact, the function can be quite comp= lex. >>> >>> I'm open to better text covering such translations. Even "manipulatio= n >>> of Data Records" (in capital letters) is not precise because if we >>> import from Netflow. Data Record is an IPFIX term. >>> >>> So, maybe just "manipulation and conversion of records"? >>> =20 >> That makes more sense to me, and would be in line with the framework, = >> where the Exporting Process is a different process >=20 > I agree. Hence, the current proposal is as follows: IPFIX Mediation IPFIX Mediation is a generic function that covers the manipulation and conversion of records. "record" can be anything, e.g. Netflow records, PSAMP Packet Reports, IPFIX Data Records,... However, Mediation does not handle messages. This is the figure I have in mind: IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages--> There are no messages entering the IP. Messages occur only at the input of the CP and at the output of the EP. Similarly, if IP is located at the Original Exporter: MP --records--> IP --records--> EP --IPFIX messages--> 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 --------------ms090600040302020204070707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE5MDgyNzQyWjAjBgkqhkiG9w0BCQQxFgQU 60wDtoMGA236Fjz4aMUta5Exv/AwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAMKL98yqNIyniEDnsvSy81g2bX7pVmRVNxNd5QMQS2f017Yp P6PxW+ZCmy+K/jVCxfLsUvB7tOUVwEDb05Ma6oh+Ukr+x1Qqv7iLktZvLNwuWDzxsZq51H12 RKNaui+kYC7kqlUcBZ+hjz/RC2rug7mRxiDSYo3TKOaiJOt3VV0001VX3JdxTlyB+RE6RvJv jkl792gHizRMmatvd35OFbGoTxCs0sMX69cMZsI/K71M+WFDjwVR6c8QxkbWyfQVfJCOy47y JmG8HX6bPQTAkYeYYBzIYZwFWpOhxmRYBdez1AKUe0L+CyNA3Hpmbcmml9mRfqzZWnLTj23p vHpzYvkAAAAAAAA= --------------ms090600040302020204070707-- From trammell@tik.ee.ethz.ch Fri Jun 19 01:56:23 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA943A6C15 for ; Fri, 19 Jun 2009 01:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 YQ9tmPAa1eyi for ; Fri, 19 Jun 2009 01:56:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 563D43A68E6 for ; Fri, 19 Jun 2009 01:56:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 392D6D937D; Fri, 19 Jun 2009 10:56:33 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bd+Hj268a1HK; Fri, 19 Jun 2009 10:56:33 +0200 (MEST) Received: from [10.0.1.11] (77-58-83-74.dclient.hispeed.ch [77.58.83.74]) (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 C4B19D9375; Fri, 19 Jun 2009 10:56:32 +0200 (MEST) Message-Id: From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090618161432.B5C8.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 10:56:32 +0200 References: <20090618161432.B5C8.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 08:56:23 -0000 On Jun 18, 2009, at 10:52 AM, Atsushi Kobayashi wrote: > > Hi Benoit, Gerhard, Brian, and all, > > In terminology section, there are main two discussion points. > > 1) the problem statement includes the more specific terms (IPFIX > Concentrator, Proxy, Masq.Proxy, Distributor), or not? > > Brian, Gerhalz points out these terms seems restrict the work at > framework, > it is better the problem statement uses the more general terms. Benoit > say it does not prefer that the discussion for the terminologies are > postponed. > > I agree the Benoit. Although I can use the general terms in problem > statement, using the terms enhances the images of the IPFIX mediation > examples. > > So, I would like to keep these terms in problem statement. Agreed... > 2) the more specific terms (IPFIX Concentrator, Proxy, Masq.Proxy, > Distributor) indicate the type of device, or a set of the functions. > > Gerhalz points out these terms are already perceived as type of > devices, for example IPFIX Concentrator in RFC3917. > Same questions arose from some NTT co-workers. Benoit say that the > "device" implies a physical entity and restricts the future functions. > > I am worried that the terms become more complex meaning after thinking > the future functions. I think that even if it is "device", it does > not seem > restrict the location in which the future functions applied. Device, in English usage, clearly means "box"; and further, from 5470, requires export: An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes. I'm okay with a Mediator being a Device. I think, though, that when composing complex mediation functions, we should compose them of functions within a single Mediator, and not, for instance, compose things out of sets of Concentrators and Proxies... We shouldn't confuse the device with what it does, and we should be talking in terms of actions now. > Because we can say that IPFIX Mediator does not implicitly require a > separate physical entity. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. > > Certainly, a IPFIX Mediator can have a set of the functions hosted in > both IPFIX Proxy and IPFIX Concentrator. In that case, the Mediator > can become IPFIX Proxy on one situation, and it can also become IPFIX > Concentrator on other situations. Of course. The point is that a Mediator is a generalization of all of the other previously envisioned IPFIX "transformation" devices/ processes. > Thus, I proposed here. > > IPFIX Proxy > > An IPFIX Proxy is a type of IPFIX Mediator that relays incoming > Transport Sessions to one or multiple Collectors. Okay... I propose the following unified terminology section, following the thread to date: IPFIX Mediation describes the manipulation and conversion of records exported using IPFIX, by applying mediation functions within one or more Intermediate Processes in an IPFIX Mediator. The following terms are used in this document to describe the architectural entities used by IPFIX Mediation. Intemediate Process An Intermediate Process takes a sequence of records from a Collecting Process, IPFIX File Reader, or another Intermediate Process within a Mediator; performs some transformation on these records based upon the content of the records themselves, state kept across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process within a Mediator. This document describes specific Intermediate Processes below used in the elaboration of the problem statement; however, this is not an exhaustive list. Intermediate Aggregation Process An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a new set of Flow Key fields, or functions applied to Flow Key fields (e.g. binning, subnet aggregation). Intermediate Correlation Process An Intermediate Correlation Process is an Intermediate Process which adds information to records noting correlations among them, or generates new records with correlated data from multiple records (e.g. the production of bidirectional flow records from unidirectional flow records). Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria evaluated record values, and passes only those records that match the criteria (e.g. filtering only records from a given network to a given Collector). Intermediate Anonymisation Process An Intermediate Anonymisation Process is an Intermediate Process that transforms records in order to anonymise them, to protect the identity of the entities described by the records (e.g. by applying prefix- preserving pseudonymisation of IP addresses). IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Specific types of Mediators are defined below; some of these reference original mediation capabilities defined in earlier IPFIX documens before the elaboration of the Mediator problem statement. IPFIX Proxy An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX Messages or messages in other protocols to one or more Collectors. It can provide transport protocol mediation and re-encoding. IPFIX Concentrator An IPFIX Concentrator is an IPFIX Mediator that recieves data from one or more Exporters and sends them to a single Collector, optionally transforming the records using zero or more Intermediate Processes on the way. IPFIX Distributor An IPFIX Distributor is an IPFIX Mediator that recieves data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Selection Process. IPFIX Masquerading Proxy An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data from one or more Exporters and sends them to a single Collector, using one or more Intermediate Aggregation Functions and Intermediate Anonymisation Functions to screen out parts of records according to configured policies, in order to protect the privacy of the network's end users or senstive data of the exporting organization. Best regards, Brian From christoph.sommer@informatik.uni-erlangen.de Fri Jun 19 03:05:46 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0496C3A69B8 for ; Fri, 19 Jun 2009 03:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH26mXaeMTk1 for ; Fri, 19 Jun 2009 03:05:45 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id CCB753A693B for ; Fri, 19 Jun 2009 03:05:44 -0700 (PDT) Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 5AD1A4B64; Fri, 19 Jun 2009 12:05:54 +0200 (MEST) 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 3A5914B8459; Fri, 19 Jun 2009 12:05:54 +0200 (CEST) Message-ID: <4A3B6302.1060402@informatik.uni-erlangen.de> Date: Fri, 19 Jun 2009 12:05:54 +0200 From: Christoph Sommer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090227 Shredder/3.0b2 ThunderBrowse/3.2.4 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <20090618161432.B5C8.17391CF2@nttv6.net> In-Reply-To: X-Enigmail-Version: 0.96a OpenPGP: id=D7F75353 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 10:05:46 -0000 Brian, all, Brian Trammell wrote: > I propose the following unified terminology section, following the > thread to date: > > IPFIX Mediation describes the manipulation and conversion of records > exported using IPFIX, by applying mediation functions within one or more > Intermediate Processes in an IPFIX Mediator. The following terms are > used in this document to describe the architectural entities used by > IPFIX Mediation. > > Intemediate Process > > An Intermediate Process takes a sequence of records from a Collecting > Process, IPFIX File Reader, or another Intermediate Process within a > Mediator; performs some transformation on these records based upon the > content of the records themselves, state kept across multiple records, > configuration parameters, or other data; and passes a sequence of > transformed records on to an Exporting Process, IPFIX File Writer, or > another Intermediate Process within a Mediator. This document describes > specific Intermediate Processes below used in the elaboration of the > problem statement; however, this is not an exhaustive list. > > Intermediate Aggregation Process > > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a new set of Flow Key fields, or functions > applied to Flow Key fields (e.g. binning, subnet aggregation). > > Intermediate Correlation Process > > An Intermediate Correlation Process is an Intermediate Process which > adds information to records noting correlations among them, or generates > new records with correlated data from multiple records (e.g. the > production of bidirectional flow records from unidirectional flow records). > > Intermediate Selection Process > > An Intermediate Selection Process is an Intermediate Process that > selects records from a sequence based upon criteria evaluated record > values, and passes only those records that match the criteria (e.g. > filtering only records from a given network to a given Collector). > > Intermediate Anonymisation Process > > An Intermediate Anonymisation Process is an Intermediate Process that > transforms records in order to anonymise them, to protect the identity > of the entities described by the records (e.g. by applying > prefix-preserving pseudonymisation of IP addresses). > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting zero or > more Intermediate Processes to transform those records, and exporting > those records in IPFIX Messages via an Exporting Process. In the common > case, a Mediator receives records from a Collecting Process, but could > also receive records from data sources not encoded using IPFIX, e.g., in > the case of NetFlow V9 protocol translation. Specific types of Mediators > are defined below; some of these reference original mediation > capabilities defined in earlier IPFIX documens before the elaboration of > the Mediator problem statement. > > IPFIX Proxy > > An IPFIX Proxy is an IPFIX Mediator that relays incoming > IPFIX Messages or messages in other protocols to one or more Collectors. > It can provide transport protocol mediation and re-encoding. > > IPFIX Concentrator > > An IPFIX Concentrator is an IPFIX Mediator that recieves data from one > or more Exporters and sends them to a single Collector, optionally > transforming the records using zero or more Intermediate Processes on > the way. > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that recieves data from one or > more Exporters and sends them to one or more Collectors, deciding which > Collector(s) to send each record to based upon the decision of an > Intermediate Selection Process. > > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data from > one or more Exporters and sends them to a single Collector, using one or > more Intermediate Aggregation Functions and Intermediate Anonymisation > Functions to screen out parts of records according to configured > policies, in order to protect the privacy of the network's end users or > senstive data of the exporting organization. I like this way of defining the processes and devices mentioned in the draft! One minor comment: Maybe the draft could also stress that (like the list of processes) the list of devices is non-exhaustive. Cheers, 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/ From bclaise@cisco.com Fri Jun 19 05:07:10 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DA028C12E for ; Fri, 19 Jun 2009 05:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.696 X-Spam-Level: X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, GB_I_LETTER=-2] 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 DIveY+7juWKI for ; Fri, 19 Jun 2009 05:07:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 328733A6879 for ; Fri, 19 Jun 2009 05:07:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JC7JFg026494; Fri, 19 Jun 2009 14:07:19 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JC7Eo8004613; Fri, 19 Jun 2009 14:07:14 +0200 (CEST) Message-ID: <4A3B7F72.9050505@cisco.com> Date: Fri, 19 Jun 2009 14:07:14 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Trammell References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:07:10 -0000 Brian Trammell wrote: > > On Jun 18, 2009, at 10:56 AM, Atsushi Kobayashi wrote: > >> >> Hi Benoit, and Gerhard, >> >>>>>> >>>>>>> maybe: >>>>>>> "...covers the manipulation of the content and transmission of Data >>>>>>> Records and IPFIX Messages." >>>>>>> >>>>>>> >>>>>> Fine. >>>>>> >>>>>> >>>>> Actually, I have a problem with this proposal, i.e. adding >>>>> "transmission" in the IPFIX Mediation definition. >>>>> >>>> >>>> Well, "transmission" was in the draft. It is not my wording. >>>> >>> Right. Sorry. >>> The draft version 3 says >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation is a generic function that covers the manipulation >>> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >>> Messages, or their transmission. >>> >>> The proposal in this thread is: >>> >>> "...covers the manipulation of the content _and _transmission of Data >>> Records and IPFIX Messages." >> >> Do you mean "the transmission of Data Records _or_ IPFIX Messages" ? >> And we also put the (Options) Template Records. >> >> Finally, next version would say. >> >> "IPFIX Mediation is a function that covers the manipulation of the >> content and transmission of Data Records, (Options) Template Records, or >> IPFIX Messages. Here is a series of IPFIX Mediation examples: >> >> * content mediation that changes Data Records information >> >> + aggregating Data Records based on a new set of Flow Key >> fields > > If we _must_. I actually prefer to keep examples out of terminology > (it still looks like it is intended as a covering set) and to define > _functions_. You have the rest of the document (and indeed, do use it) > to talk about the examples. This makes sense. Regards, Benoit. > > Again, where we do speak specifically, I think we want to talk > explicitly in terms of defined intermediate processes (e.g., > Intermediate Aggregation Process, Intermediate Selection Process, and > so on), and not try to wedge a covering set of mediation functions > into a definition "IPFIX Mediation" that isn't really used anywhere > (i.e., the _document_ talks about IPFIX Mediation, but all of the > terms to which specifications can be meaningfully applied -- devices, > processes functions -- are at a lower level...) > >>> The difference now is "and". This means that we always "transmit" in >>> the >>> mediation >>> If "transmit" is perceived as "exported", then I have a problem >>>> "transmission" relates to the translation of Netflow into IPFIX etc. >>>> Do to this, I assume that an Intermediate Process is needed because >>>> the >>>> records need to be converted. In fact, the function can be quite >>>> complex. >>>> >>>> I'm open to better text covering such translations. Even "manipulation >>>> of Data Records" (in capital letters) is not precise because if we >>>> import from Netflow. Data Record is an IPFIX term. >>>> >>>> So, maybe just "manipulation and conversion of records"? >>>> >>> That makes more sense to me, and would be in line with the framework, >>> where the Exporting Process is a different process >>>> >> >> I agree. >> >> Regards, >> Atsushi >> >> --- >> 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 bclaise@cisco.com Fri Jun 19 05:14:09 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A42E3A6ACF for ; Fri, 19 Jun 2009 05:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.771 X-Spam-Level: X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzGn-LJniAGC for ; Fri, 19 Jun 2009 05:14:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 1EC973A6AD7 for ; Fri, 19 Jun 2009 05:14:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JCEJWL026989; Fri, 19 Jun 2009 14:14:19 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JCEJja016054; Fri, 19 Jun 2009 14:14:19 +0200 (CEST) Message-ID: <4A3B811B.9010701@cisco.com> Date: Fri, 19 Jun 2009 14:14:19 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerhard Muenz References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> <4A3B4BFE.5040604@net.in.tum.de> In-Reply-To: <4A3B4BFE.5040604@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------000900080708010508030000" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:14:09 -0000 This is a multi-part message in MIME format. --------------000900080708010508030000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Gerhard, > >>> The difference now is "and". This means that we always "transmit" in the >>> mediation >>> If "transmit" is perceived as "exported", then I have a problem >>> >>>> "transmission" relates to the translation of Netflow into IPFIX etc. >>>> Do to this, I assume that an Intermediate Process is needed because the >>>> records need to be converted. In fact, the function can be quite complex. >>>> >>>> I'm open to better text covering such translations. Even "manipulation >>>> of Data Records" (in capital letters) is not precise because if we >>>> import from Netflow. Data Record is an IPFIX term. >>>> >>>> So, maybe just "manipulation and conversion of records"? >>>> >>>> >>> That makes more sense to me, and would be in line with the framework, >>> where the Exporting Process is a different process >>> >> I agree. >> > > Hence, the current proposal is as follows: > > IPFIX Mediation > IPFIX Mediation is a generic function that covers the manipulation > and conversion of records. > > "record" can be anything, e.g. Netflow records, PSAMP Packet Reports, > IPFIX Data Records,... > However, Mediation does not handle messages. > Agreed on the principles. I would like to introduce somewhere in the terminology that we speak primarily about IPFIX Data Records and PSAMP Packet Reports Do you agree with the proposal? IPFIX Mediation IPFIX Mediation is a generic function that covers the manipulation and conversion of Data Records, such as IPFIX Flow Records and PSAMP Packet Reports. Justification, the Data Record definition from RFC5101 seems perfect for what we want to express. Regards, Benoit. > This is the figure I have in mind: > > IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages--> > > There are no messages entering the IP. Messages occur only at the input > of the CP and at the output of the EP. > > Similarly, if IP is located at the Original Exporter: > > MP --records--> IP --records--> EP --IPFIX messages--> > > Gerhard > > --------------000900080708010508030000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gerhard, 
  
The difference now is "and". This means that we always "transmit" in the 
mediation
If "transmit" is perceived as "exported", then I have a problem
      
"transmission" relates to the translation of Netflow into IPFIX etc.
Do to this, I assume that an Intermediate Process is needed because the
records need to be converted. In fact, the function can be quite complex.

I'm open to better text covering such translations. Even "manipulation
of Data Records" (in capital letters) is not precise because if we
import from Netflow. Data Record is an IPFIX term.

So, maybe just "manipulation and conversion of records"?
  
        
That makes more sense to me, and would be in line with the framework, 
where the Exporting Process is a different process
      
I agree.
    

Hence, the current proposal is as follows:

 IPFIX Mediation
     IPFIX Mediation is a generic function that covers the manipulation
     and conversion of records.

"record" can be anything, e.g. Netflow records, PSAMP Packet Reports,
IPFIX Data Records,...
However, Mediation does not handle messages.
Agreed on the principles.
I would like to introduce somewhere in the terminology that we speak primarily about IPFIX Data Records and PSAMP Packet Reports
Do you agree with the proposal?
   IPFIX Mediation

      IPFIX Mediation is a generic function that covers the manipulation
      and conversion of Data Records, such as IPFIX Flow Records and PSAMP Packet Reports.

Justification, the Data Record definition from RFC5101 seems perfect for what we want to express.
Regards, Benoit.
This is the figure I have in mind:

IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages-->

There are no messages entering the IP. Messages occur only at the input
of the CP and at the output of the EP.

Similarly, if IP is located at the Original Exporter:

MP --records--> IP --records--> EP --IPFIX messages-->

Gerhard

--------------000900080708010508030000-- From trammell@tik.ee.ethz.ch Fri Jun 19 05:19:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A9FF3A69D6 for ; Fri, 19 Jun 2009 05:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, GB_I_LETTER=-2, 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 811CWMmTSJyI for ; Fri, 19 Jun 2009 05:19:12 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 7D0013A69F9 for ; Fri, 19 Jun 2009 05:19:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7F456D93A0; Fri, 19 Jun 2009 14:19:17 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YgT1OuFIMATy; Fri, 19 Jun 2009 14:19:17 +0200 (MEST) Received: from [10.0.1.11] (77-58-83-74.dclient.hispeed.ch [77.58.83.74]) (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 D73BDD938A; Fri, 19 Jun 2009 14:19:16 +0200 (MEST) Message-Id: From: Brian Trammell To: Benoit Claise In-Reply-To: <4A3B811B.9010701@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 14:19:16 +0200 References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> <4A3B4BFE.5040604@net.in.tum.de> <4A3B811B.9010701@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:19:13 -0000 hi, Benoit, Yes. s/record/Data Record/g in my previous rewrite of the terminology section. Regards, Brian On Jun 19, 2009, at 2:14 PM, Benoit Claise wrote: > Gerhard, >> >> >>>> The difference now is "and". This means that we always "transmit" >>>> in the >>>> mediation >>>> If "transmit" is perceived as "exported", then I have a problem >>>> >>>>> "transmission" relates to the translation of Netflow into IPFIX >>>>> etc. >>>>> Do to this, I assume that an Intermediate Process is needed >>>>> because the >>>>> records need to be converted. In fact, the function can be quite >>>>> complex. >>>>> >>>>> I'm open to better text covering such translations. Even >>>>> "manipulation >>>>> of Data Records" (in capital letters) is not precise because if we >>>>> import from Netflow. Data Record is an IPFIX term. >>>>> >>>>> So, maybe just "manipulation and conversion of records"? >>>>> >>>>> >>>> That makes more sense to me, and would be in line with the >>>> framework, >>>> where the Exporting Process is a different process >>>> >>> I agree. >>> >> >> Hence, the current proposal is as follows: >> >> IPFIX Mediation >> IPFIX Mediation is a generic function that covers the >> manipulation >> and conversion of records. >> >> "record" can be anything, e.g. Netflow records, PSAMP Packet Reports, >> IPFIX Data Records,... >> However, Mediation does not handle messages. >> > Agreed on the principles. > I would like to introduce somewhere in the terminology that we speak > primarily about IPFIX Data Records and PSAMP Packet Reports > Do you agree with the proposal? > IPFIX Mediation > > IPFIX Mediation is a generic function that covers the > manipulation > and conversion of Data Records, such as IPFIX Flow Records and > PSAMP Packet Reports. > > Justification, the Data Record definition from RFC5101 seems perfect > for what we want to express. > Regards, Benoit. >> This is the figure I have in mind: >> >> IPFIX messages--> CP --records--> IP --records--> EP --IPFIX >> messages--> >> >> There are no messages entering the IP. Messages occur only at the >> input >> of the CP and at the output of the EP. >> >> Similarly, if IP is located at the Original Exporter: >> >> MP --records--> IP --records--> EP --IPFIX messages--> >> >> Gerhard >> >> > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Fri Jun 19 13:08:54 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E3A3A68D7 for ; Fri, 19 Jun 2009 13:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.223, 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 4YB8LzRpotoq for ; Fri, 19 Jun 2009 13:08:53 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id F38273A6840 for ; Fri, 19 Jun 2009 13:08:52 -0700 (PDT) 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 03238481D8; Fri, 19 Jun 2009 22:09:04 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 125D15409; Fri, 19 Jun 2009 22:09:02 +0200 (CEST) Message-ID: <4A3BF0B4.20104@net.in.tum.de> Date: Fri, 19 Jun 2009 22:10:28 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Trammell References: <20090618161432.B5C8.17391CF2@nttv6.net> In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020904090109030606090701" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 20:08:54 -0000 This is a cryptographically signed message in MIME format. --------------ms020904090109030606090701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, I'm not sure if we need all this information in the terminology section. Maybe, there is a better place them, either in another section of the draft or in the framework draft. BTW, there are several problems with your definitions. See inline. Regards, Gerhard Brian Trammell wrote: > I propose the following unified terminology section, following the > thread to date: >=20 > IPFIX Mediation describes the manipulation and conversion of records > exported using IPFIX, by applying mediation functions within one or mor= e "exported using IPFIX" should be removed, because they could have been exported using Netflow. > Intermediate Processes in an IPFIX Mediator. The following terms are > used in this document to describe the architectural entities used by > IPFIX Mediation. >=20 > Intemediate Process >=20 > An Intermediate Process takes a sequence of records from a Collecting > Process, IPFIX File Reader, or another Intermediate Process within a The Metering Process is missing as a source of records. I wonder if we have to specify the sources at all. > Mediator; performs some transformation on these records based upon the > content of the records themselves, state kept across multiple records, > configuration parameters, or other data; and passes a sequence of > transformed records on to an Exporting Process, IPFIX File Writer, or > another Intermediate Process within a Mediator. This document describes= Again, do we have to specify the sinks here? > specific Intermediate Processes below used in the elaboration of the > problem statement; however, this is not an exhaustive list. >=20 > Intermediate Aggregation Process >=20 > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a new set of Flow Key fields, or function= s > applied to Flow Key fields (e.g. binning, subnet aggregation). It is also possible to aggregate PSAMP Packet Reports that do not have Flow Keys! So, we cannot assume that the original records have flow key fields. > Intermediate Correlation Process >=20 > An Intermediate Correlation Process is an Intermediate Process which > adds information to records noting correlations among them, or generate= s > new records with correlated data from multiple records (e.g. the > production of bidirectional flow records from unidirectional flow recor= ds). >=20 > Intermediate Selection Process >=20 > An Intermediate Selection Process is an Intermediate Process that > selects records from a sequence based upon criteria evaluated record > values, and passes only those records that match the criteria (e.g. > filtering only records from a given network to a given Collector). >=20 > Intermediate Anonymisation Process >=20 > An Intermediate Anonymisation Process is an Intermediate Process that > transforms records in order to anonymise them, to protect the identity > of the entities described by the records (e.g. by applying > prefix-preserving pseudonymisation of IP addresses). >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting zero o= r > more Intermediate Processes to transform those records, and exporting > those records in IPFIX Messages via an Exporting Process. In the common= > case, a Mediator receives records from a Collecting Process, but could What about records from a Metering Process? > also receive records from data sources not encoded using IPFIX, e.g., i= n > the case of NetFlow V9 protocol translation. Specific types of Mediator= s > are defined below; some of these reference original mediation > capabilities defined in earlier IPFIX documens before the elaboration o= f > the Mediator problem statement. >=20 > IPFIX Proxy >=20 > An IPFIX Proxy is an IPFIX Mediator that relays incoming > IPFIX Messages or messages in other protocols to one or more Collectors= =2E > It can provide transport protocol mediation and re-encoding. >=20 > IPFIX Concentrator >=20 > An IPFIX Concentrator is an IPFIX Mediator that recieves data from one > or more Exporters and sends them to a single Collector, optionally > transforming the records using zero or more Intermediate Processes on > the way. >=20 > IPFIX Distributor >=20 > An IPFIX Distributor is an IPFIX Mediator that recieves data from one o= r > more Exporters and sends them to one or more Collectors, deciding which= > Collector(s) to send each record to based upon the decision of an > Intermediate Selection Process. >=20 > IPFIX Masquerading Proxy >=20 > An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data fro= m > one or more Exporters and sends them to a single Collector, using one o= r > more Intermediate Aggregation Functions and Intermediate Anonymisation > Functions to screen out parts of records according to configured > policies, in order to protect the privacy of the network's end users or= > senstive data of the exporting organization. >=20 >=20 > Best regards, >=20 > Brian > _______________________________________________ > 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 --------------ms020904090109030606090701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE5MjAxMDI4WjAjBgkqhkiG9w0BCQQxFgQU h2h3AcewVCMdprFkORy9xGjRv+MwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALC/R7NmYf48uwbY+EFflRl2PU9VAOaHJQa5ATKUbnMgSnuh OIhno9KjNJwKio9Vpsyvw3otMJV9ZGE6+yTdM491hYOpKRcx1gp7TtINS8SxmsRMRDQk8qUE BxgPa0ccELwtD2tKr1SF0eIF5akbtTVmhPABfJIr3G/uWh0X+odyqlsKFwv3AXM6zbtj4Xcq akoqur5bV4C43wmvR15lnMKeTxYEBMyO679892hd6LlRtCnYDJC0RfX6bm8lCCKTAL4rw28Q 0j/GPRnpbSTzileewP9wjSB/VZ82UrbbjBXYlT+qE75NgYGebhLv7mqwNi5+yhS1eC0r/OsI aOtUz28AAAAAAAA= --------------ms020904090109030606090701-- From muenz@net.in.tum.de Fri Jun 19 13:18:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8D73A6A91 for ; Fri, 19 Jun 2009 13:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.795, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gagzNEKWh6DU for ; Fri, 19 Jun 2009 13:18:24 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 6A9393A6840 for ; Fri, 19 Jun 2009 13:18:24 -0700 (PDT) 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 7AD85481D8; Fri, 19 Jun 2009 22:18:36 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 7F5AD5409; Fri, 19 Jun 2009 22:18:35 +0200 (CEST) Message-ID: <4A3BF2F0.6080303@net.in.tum.de> Date: Fri, 19 Jun 2009 22:20:00 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Benoit Claise References: <4A38E537.6080208@net.in.tum.de> <4A38F1F4.5030706@cisco.com> <20090618175305.B5CB.17391CF2@nttv6.net> <4A3B4BFE.5040604@net.in.tum.de> <4A3B811B.9010701@cisco.com> In-Reply-To: <4A3B811B.9010701@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040700010704000200030007" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 20:18:25 -0000 This is a cryptographically signed message in MIME format. --------------ms040700010704000200030007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Benoit, Benoit Claise wrote: > Gerhard, >> =20 >>>> The difference now is "and". This means that we always "transmit" in= the=20 >>>> mediation >>>> If "transmit" is perceived as "exported", then I have a problem >>>> =20 >>>>> "transmission" relates to the translation of Netflow into IPFIX etc= =2E >>>>> Do to this, I assume that an Intermediate Process is needed because= the >>>>> records need to be converted. In fact, the function can be quite co= mplex. >>>>> >>>>> I'm open to better text covering such translations. Even "manipulat= ion >>>>> of Data Records" (in capital letters) is not precise because if we >>>>> import from Netflow. Data Record is an IPFIX term. >>>>> >>>>> So, maybe just "manipulation and conversion of records"? >>>>> =20 >>>>> =20 >>>> That makes more sense to me, and would be in line with the framework= ,=20 >>>> where the Exporting Process is a different process >>>> =20 >>> I agree. >>> =20 >> >> Hence, the current proposal is as follows: >> >> IPFIX Mediation >> IPFIX Mediation is a generic function that covers the manipulatio= n >> and conversion of records. >> >> "record" can be anything, e.g. Netflow records, PSAMP Packet Reports, >> IPFIX Data Records,... >> However, Mediation does not handle messages. >> =20 > Agreed on the principles. > I would like to introduce somewhere in the terminology that we speak > primarily about IPFIX Data Records and PSAMP Packet Reports > Do you agree with the proposal? >=20 > IPFIX Mediation >=20 > IPFIX Mediation is a generic function that covers the manipulatio= n > and conversion of Data Records, such as IPFIX Flow Records and PS= AMP Packet Reports. >=20 > Justification, the Data Record definition from RFC5101 seems perfect fo= r what we want to express.=20 Ok with me. Yet, it should be clear that Data Record is not restricted to IPFIX Data Records but also covers Netflow records etc. Therefore, I'm not sure if capital letters are correct. 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 --------------ms040700010704000200030007 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjE5MjAyMDAwWjAjBgkqhkiG9w0BCQQxFgQU +q5tnOTagJZoKcKP/Trjfo7aRFgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAH/NqKWrNcB8BkLfGgwGZdEmj7JWVIJPN71MuJBOM/jdZphZ yuX8ktep9TEkd+EyPzq7w/oRVr93DlOGwPYut1LXzb9PiS51OEDNsVFrOWcpO31nKCHP7pK/ b5eutkW4RZtf+38qtbvQxM2NBEZAeyORmAzSD6t/ym0nmhOgqkFXV6rbcV8mlVjeTG1bWXpg /nXzBE2AJMvsaHd1FYtho8RjmivqmFqNTyfRfbLPxXrboO0b0VibYGS1S6jVA9Z23j3mPdj0 /dArVed3L2d0D04/wAWEZEKVo1cKWyhADukk1kdlL4r7ks0SEjAzEIWlv1kadwlov3ayLeF7 roKl/eMAAAAAAAA= --------------ms040700010704000200030007-- From bclaise@cisco.com Fri Jun 19 16:57:31 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 977AC3A6A4E for ; Fri, 19 Jun 2009 16:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 x9NGPT34Qtif for ; Fri, 19 Jun 2009 16:57:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 5BF203A6452 for ; Fri, 19 Jun 2009 16:57:30 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JNvdfp016578; Sat, 20 Jun 2009 01:57:39 +0200 (CEST) Received: from [10.55.43.55] (ams-bclaise-8716.cisco.com [10.55.43.55]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5JNvSkY011519; Sat, 20 Jun 2009 01:57:31 +0200 (CEST) Message-ID: <4A3C25E4.2040005@cisco.com> Date: Sat, 20 Jun 2009 01:57:24 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A3805EC.3010702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 23:57:31 -0000 Dan > Hi Benoit, > > Yes, this is the type of information that I was looking for. My reading > of your answer is that the impact of adding SCTP streams in an existing > session versus opening a new SCTP session is minor, with a possible plus > of efficiency at setup time. Processing overhead and message overhead > may potentially be a problem, and care should be exercised in deployment > in order to understand the effects. > > Can we add corresponding text on this? > Here is our proposal: What is the performance impact regarding the implementation of these specifications compared to the IPFIX protocol [RFC5101]? Although adding the new SCTP streams requires a message exchange, it is more lightweight to set up additional SCTP streams than to set up a new SCTP association since the only overhead of adding stream(s) to an existing SCTP association is the addition of 16-24 more bytes (allocated in the SCTP association, a single time), whereas setting up a new SCTP association implies more overhead. In terms of of throughput impact, the fact that these specifications discourage multiplexing Templates and Data Records of different Template IDs may lead to a slightly larger IPFIX Message overhead. If the Data Record rate is low for a specific Template (hence a specific SCTP stream), the Exporting Process might not be able to fill the IPFIX Messages as fully as possible. In such a situation, we could potentially have an overhead due to additional IPFIX Message headers and SCTP chunk headers. Finally, with respect to the processing overhead on the Exporter, a lot of state information must be stored when a large number of SCTP streams are used with an SCTP association. The authors have not yet been able to compare the performance impact of multiple streams within an SCTP association versus opening the same number of independent SCTP associations. Fine with you? Regards, Benoit. > Thanks and Regards, > > Dan > > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Tuesday, June 16, 2009 11:52 PM >> To: Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei >> (peterlei); Michael Tuexen >> Subject: Re: [IPFIX] AD Review of >> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on >> performance and capacity >> >> Dan, >> >>> Please find below the AD review for >>> draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature >>> enough to go to IETF Last Call. Unless there are any >>> >> special comments >> >>> or concerns I will send it to IETF Last Call by tomorrow. >>> >>> Please consider the comments below together with the other >>> >> IETF Last >> >>> Call comments. The comments are divided into Technical and Editorial >>> >>> T1. There is not information concerning the impact on >>> >> performance and >> >>> capacity of the reporting and collecting processes. Should >>> >> we expect >> >>> any considerable impact on performance and/or capacity? If any >>> implementation experience is available I would suggest that >>> >> we record >> >>> it. >>> >>> >> Collecting information from the authors of >> draft-stewart-tsvwg-sctpstrrst and >> draft-ietf-ipfix-export-per-sctp-stream-02, here are the conclusions: >> * We were not too sure what is meant by "performance and >> capacity" in this context. >> * If the question is about: What's the impact of additional >> SCTP streams in an existing session versus opening a new SCTP >> session? The impact is >> minor: >> - You have of course a message exchange to add the streams. >> - You end up adding 16-24 bytes per stream. >> - It is more lightweight to set up additional streams >> compared to setting up a new association. >> The only thing that comes into my mind is throughput which >> * If the question is about the throughput that could be >> impaired by processing overhead and message overhead. >> - With respect of processing overhead, I have no idea how the >> utilization of a large number of streams influences the >> performance of the SCTP socket. I could imagine that a lot of >> state information must be stored. >> - With respect of message overhead, we can say that the fact >> that we discourage multiplexing templates and data records of >> different template ids may lead to a larger message overhead. >> If the data record rate is low for a specific template, the >> exporting process might not be able to optimally fill the >> IPFIX messages. Hence, we have more overhead due to >> additional IPFIX message headers and SCTP chunk headers. >> >> Is this what you have in mind? >> >> Regards, Benoit. >> >> >> From dromasca@avaya.com Sun Jun 21 05:21:24 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5953A6C60 for ; Sun, 21 Jun 2009 05:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 bK+pdP2aWPZk for ; Sun, 21 Jun 2009 05:21:23 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 4D6913A6C89 for ; Sun, 21 Jun 2009 05:21:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,262,1243828800"; d="scan'208";a="164925325" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 21 Jun 2009 08:21:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jun 2009 08:21:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Jun 2009 14:21:25 +0200 Message-ID: In-Reply-To: <4A3C25E4.2040005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity thread-index: AcnxObzz0a9fbGfTTWqkaTkGDmu8gwBLggVA References: <4A3805EC.3010702@cisco.com> <4A3C25E4.2040005@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: "Peter Lei \(peterlei\)" , Michael Tuexen , IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 12:21:24 -0000 This looks fine to me. As an editorial observation, it is good to avoid 'personalized' style in such specifications like the usage of 'we' and 'the authors'. Impersonal modes are better.=20 Thanks for addressing this comment.=20 Dan =20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Saturday, June 20, 2009 2:57 AM > To: Romascanu, Dan (Dan) > Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20 > (peterlei); Michael Tuexen > Subject: Re: [IPFIX] AD Review of=20 > draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 > performance and capacity >=20 > Dan > > Hi Benoit, > > > > Yes, this is the type of information that I was looking for. My=20 > > reading of your answer is that the impact of adding SCTP=20 > streams in an=20 > > existing session versus opening a new SCTP session is minor, with a=20 > > possible plus of efficiency at setup time. Processing overhead and=20 > > message overhead may potentially be a problem, and care should be=20 > > exercised in deployment in order to understand the effects. > > > > Can we add corresponding text on this?=20 > > =20 > Here is our proposal: >=20 > What is the performance impact regarding the implementation=20 > of these specifications compared to the IPFIX protocol [RFC5101]? >=20 > Although adding the new SCTP streams requires a message=20 > exchange, it is more lightweight to set up additional SCTP=20 > streams than to set up a new SCTP association since the only=20 > overhead of adding stream(s) to an existing SCTP association=20 > is the addition of 16-24 more bytes (allocated in the SCTP=20 > association, a single time), whereas setting up a new SCTP=20 > association implies more overhead. >=20 > In terms of of throughput impact, the fact that these=20 > specifications discourage multiplexing Templates and Data=20 > Records of different Template IDs may lead to a slightly=20 > larger IPFIX Message overhead. If the Data Record rate is low=20 > for a specific Template (hence a specific SCTP stream), the=20 > Exporting Process might not be able to fill the IPFIX=20 > Messages as fully as possible. In such a situation, we could=20 > potentially have an overhead due to additional IPFIX Message=20 > headers and SCTP chunk headers. >=20 > Finally, with respect to the processing overhead on the=20 > Exporter, a lot of state information must be stored when a=20 > large number of SCTP streams are used with an SCTP=20 > association. The authors have not yet been able to compare=20 > the performance impact of multiple streams within an SCTP=20 > association versus opening the same number of independent=20 > SCTP associations. >=20 > Fine with you? >=20 > Regards, Benoit. > > Thanks and Regards, > > > > Dan > > > > > > =20 > >> -----Original Message----- > >> From: Benoit Claise [mailto:bclaise@cisco.com] > >> Sent: Tuesday, June 16, 2009 11:52 PM > >> To: Romascanu, Dan (Dan) > >> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20 > (peterlei);=20 > >> Michael Tuexen > >> Subject: Re: [IPFIX] AD Review of > >> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 > performance=20 > >> and capacity > >> > >> Dan, > >> =20 > >>> Please find below the AD review for > >>> draft-ietf-ipfix-export-per-sctp-stream-02. The document=20 > is mature=20 > >>> enough to go to IETF Last Call. Unless there are any > >>> =20 > >> special comments > >> =20 > >>> or concerns I will send it to IETF Last Call by tomorrow. > >>> > >>> Please consider the comments below together with the other > >>> =20 > >> IETF Last > >> =20 > >>> Call comments. The comments are divided into Technical=20 > and Editorial > >>> > >>> T1. There is not information concerning the impact on > >>> =20 > >> performance and > >> =20 > >>> capacity of the reporting and collecting processes. Should > >>> =20 > >> we expect > >> =20 > >>> any considerable impact on performance and/or capacity? If any=20 > >>> implementation experience is available I would suggest that > >>> =20 > >> we record > >> =20 > >>> it. > >>> =20 > >>> =20 > >> Collecting information from the authors of=20 > >> draft-stewart-tsvwg-sctpstrrst and=20 > >> draft-ietf-ipfix-export-per-sctp-stream-02, here are the=20 > conclusions: > >> * We were not too sure what is meant by "performance and=20 > capacity" in=20 > >> this context. > >> * If the question is about: What's the impact of additional SCTP=20 > >> streams in an existing session versus opening a new SCTP=20 > session? The=20 > >> impact is > >> minor: > >> - You have of course a message exchange to add the streams. > >> - You end up adding 16-24 bytes per stream. > >> - It is more lightweight to set up additional streams compared to=20 > >> setting up a new association. > >> The only thing that comes into my mind is throughput which > >> * If the question is about the throughput that could be=20 > impaired by=20 > >> processing overhead and message overhead. > >> - With respect of processing overhead, I have no idea how the=20 > >> utilization of a large number of streams influences the=20 > performance=20 > >> of the SCTP socket. I could imagine that a lot of state=20 > information=20 > >> must be stored. > >> - With respect of message overhead, we can say that the=20 > fact that we=20 > >> discourage multiplexing templates and data records of different=20 > >> template ids may lead to a larger message overhead. > >> If the data record rate is low for a specific template,=20 > the exporting=20 > >> process might not be able to optimally fill the IPFIX messages.=20 > >> Hence, we have more overhead due to additional IPFIX=20 > message headers=20 > >> and SCTP chunk headers. > >> > >> Is this what you have in mind? > >> > >> Regards, Benoit. > >> > >> > >> =20 >=20 >=20 From bclaise@cisco.com Sun Jun 21 05:31:35 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB3228B23E for ; Sun, 21 Jun 2009 05:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP6j92z30jll for ; Sun, 21 Jun 2009 05:31:34 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id D38E53A6834 for ; Sun, 21 Jun 2009 05:31:33 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5LCVik2015909; Sun, 21 Jun 2009 14:31:45 +0200 (CEST) Received: from [10.55.43.56] (ams-bclaise-8717.cisco.com [10.55.43.56]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5LCVg1g005158; Sun, 21 Jun 2009 14:31:42 +0200 (CEST) Message-ID: <4A3E282E.1050302@cisco.com> Date: Sun, 21 Jun 2009 14:31:42 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A3805EC.3010702@cisco.com> <4A3C25E4.2040005@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050803040503060602030303" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 12:31:35 -0000 This is a multi-part message in MIME format. --------------050803040503060602030303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, Thanks. I'll apply the changes What is the next step? You mentioned on your June 15th: Please find below the AD review for draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature enough to go to IETF Last Call. Unless there are any special comments or concerns I will send it to IETF Last Call by tomorrow. Do you want a quick updated version? Regards, Benoit > This looks fine to me. As an editorial observation, it is good to avoid > 'personalized' style in such specifications like the usage of 'we' and > 'the authors'. Impersonal modes are better. > > Thanks for addressing this comment. > > Dan > > > >> -----Original Message----- >> From: Benoit Claise [mailto:bclaise@cisco.com] >> Sent: Saturday, June 20, 2009 2:57 AM >> To: Romascanu, Dan (Dan) >> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei >> (peterlei); Michael Tuexen >> Subject: Re: [IPFIX] AD Review of >> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on >> performance and capacity >> >> Dan >> >>> Hi Benoit, >>> >>> Yes, this is the type of information that I was looking for. My >>> reading of your answer is that the impact of adding SCTP >>> >> streams in an >> >>> existing session versus opening a new SCTP session is minor, with a >>> possible plus of efficiency at setup time. Processing overhead and >>> message overhead may potentially be a problem, and care should be >>> exercised in deployment in order to understand the effects. >>> >>> Can we add corresponding text on this? >>> >>> >> Here is our proposal: >> >> What is the performance impact regarding the implementation >> of these specifications compared to the IPFIX protocol [RFC5101]? >> >> Although adding the new SCTP streams requires a message >> exchange, it is more lightweight to set up additional SCTP >> streams than to set up a new SCTP association since the only >> overhead of adding stream(s) to an existing SCTP association >> is the addition of 16-24 more bytes (allocated in the SCTP >> association, a single time), whereas setting up a new SCTP >> association implies more overhead. >> >> In terms of of throughput impact, the fact that these >> specifications discourage multiplexing Templates and Data >> Records of different Template IDs may lead to a slightly >> larger IPFIX Message overhead. If the Data Record rate is low >> for a specific Template (hence a specific SCTP stream), the >> Exporting Process might not be able to fill the IPFIX >> Messages as fully as possible. In such a situation, we could >> potentially have an overhead due to additional IPFIX Message >> headers and SCTP chunk headers. >> >> Finally, with respect to the processing overhead on the >> Exporter, a lot of state information must be stored when a >> large number of SCTP streams are used with an SCTP >> association. The authors have not yet been able to compare >> the performance impact of multiple streams within an SCTP >> association versus opening the same number of independent >> SCTP associations. >> >> Fine with you? >> >> Regards, Benoit. >> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Benoit Claise [mailto:bclaise@cisco.com] >>>> Sent: Tuesday, June 16, 2009 11:52 PM >>>> To: Romascanu, Dan (Dan) >>>> Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei >>>> >> (peterlei); >> >>>> Michael Tuexen >>>> Subject: Re: [IPFIX] AD Review of >>>> draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on >>>> >> performance >> >>>> and capacity >>>> >>>> Dan, >>>> >>>> >>>>> Please find below the AD review for >>>>> draft-ietf-ipfix-export-per-sctp-stream-02. The document >>>>> >> is mature >> >>>>> enough to go to IETF Last Call. Unless there are any >>>>> >>>>> >>>> special comments >>>> >>>> >>>>> or concerns I will send it to IETF Last Call by tomorrow. >>>>> >>>>> Please consider the comments below together with the other >>>>> >>>>> >>>> IETF Last >>>> >>>> >>>>> Call comments. The comments are divided into Technical >>>>> >> and Editorial >> >>>>> T1. There is not information concerning the impact on >>>>> >>>>> >>>> performance and >>>> >>>> >>>>> capacity of the reporting and collecting processes. Should >>>>> >>>>> >>>> we expect >>>> >>>> >>>>> any considerable impact on performance and/or capacity? If any >>>>> implementation experience is available I would suggest that >>>>> >>>>> >>>> we record >>>> >>>> >>>>> it. >>>>> >>>>> >>>>> >>>> Collecting information from the authors of >>>> draft-stewart-tsvwg-sctpstrrst and >>>> draft-ietf-ipfix-export-per-sctp-stream-02, here are the >>>> >> conclusions: >> >>>> * We were not too sure what is meant by "performance and >>>> >> capacity" in >> >>>> this context. >>>> * If the question is about: What's the impact of additional SCTP >>>> streams in an existing session versus opening a new SCTP >>>> >> session? The >> >>>> impact is >>>> minor: >>>> - You have of course a message exchange to add the streams. >>>> - You end up adding 16-24 bytes per stream. >>>> - It is more lightweight to set up additional streams compared to >>>> setting up a new association. >>>> The only thing that comes into my mind is throughput which >>>> * If the question is about the throughput that could be >>>> >> impaired by >> >>>> processing overhead and message overhead. >>>> - With respect of processing overhead, I have no idea how the >>>> utilization of a large number of streams influences the >>>> >> performance >> >>>> of the SCTP socket. I could imagine that a lot of state >>>> >> information >> >>>> must be stored. >>>> - With respect of message overhead, we can say that the >>>> >> fact that we >> >>>> discourage multiplexing templates and data records of different >>>> template ids may lead to a larger message overhead. >>>> If the data record rate is low for a specific template, >>>> >> the exporting >> >>>> process might not be able to optimally fill the IPFIX messages. >>>> Hence, we have more overhead due to additional IPFIX >>>> >> message headers >> >>>> and SCTP chunk headers. >>>> >>>> Is this what you have in mind? >>>> >>>> Regards, Benoit. >>>> >>>> >>>> >>>> >> --------------050803040503060602030303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan,

Thanks. I'll apply the changes
What is the next step?
You mentioned on your June 15th:
Please find below the AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
enough to go to IETF Last Call. Unless there are any special comments or
concerns I will send it to IETF Last Call by tomorrow.
Do you want a quick updated version?

Regards, Benoit

This looks fine to me. As an editorial observation, it is good to avoid
'personalized' style in such specifications like the usage of 'we' and
'the authors'. Impersonal modes are better. 

Thanks for addressing this comment. 

Dan
 

  
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com] 
Sent: Saturday, June 20, 2009 2:57 AM
To: Romascanu, Dan (Dan)
Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei 
(peterlei); Michael Tuexen
Subject: Re: [IPFIX] AD Review of 
draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on 
performance and capacity

Dan
    
Hi Benoit,

Yes, this is the type of information that I was looking for. My 
reading of your answer is that the impact of adding SCTP 
      
streams in an 
    
existing session versus opening a new SCTP session is minor, with a 
possible plus of efficiency at setup time. Processing overhead and 
message overhead may potentially be a problem, and care should be 
exercised in deployment in order to understand the effects.

Can we add corresponding text on this? 
  
      
Here is our proposal:

What is the performance impact regarding the implementation 
of these specifications compared to the IPFIX protocol [RFC5101]?

Although adding the new SCTP streams requires a message 
exchange, it is more lightweight to set up additional SCTP 
streams than to set up a new SCTP association since the only 
overhead of adding stream(s) to an existing SCTP association 
is the addition of 16-24 more bytes (allocated in the SCTP 
association, a single time), whereas setting up a new SCTP 
association implies more overhead.

In terms of of throughput impact, the fact that these 
specifications discourage multiplexing Templates and Data 
Records of different Template IDs may lead to a slightly 
larger IPFIX Message overhead. If the Data Record rate is low 
for a specific Template (hence a specific SCTP stream), the 
Exporting Process might not be able to fill the IPFIX 
Messages as fully as possible. In such a situation, we could 
potentially have an overhead due to additional IPFIX Message 
headers and SCTP chunk headers.

Finally, with respect to the processing overhead on the 
Exporter, a lot of state information must be stored when a 
large number of SCTP streams are used with an SCTP 
association. The authors have not yet been able to compare 
the performance impact of multiple streams within an SCTP 
association versus opening the same number of independent 
SCTP associations.

Fine with you?

Regards, Benoit.
    
Thanks and Regards,

Dan


  
      
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, June 16, 2009 11:52 PM
To: Romascanu, Dan (Dan)
Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei 
        
(peterlei); 
    
Michael Tuexen
Subject: Re: [IPFIX] AD Review of
draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on 
        
performance 
    
and capacity

Dan,
    
        
Please find below the AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document 
          
is mature 
    
enough to go to IETF Last Call. Unless there are any
      
          
special comments
    
        
or concerns I will send it to IETF Last Call by tomorrow.

Please consider the comments below together with the other
      
          
IETF Last
    
        
Call comments. The comments are divided into Technical 
          
and Editorial
    
T1. There is not information concerning the impact on
      
          
performance and
    
        
capacity of the reporting and collecting processes. Should
      
          
we expect
    
        
any considerable impact on performance and/or capacity? If any 
implementation experience is available I would suggest that
      
          
we record
    
        
it.
  
      
          
Collecting information from the authors of 
draft-stewart-tsvwg-sctpstrrst and 
draft-ietf-ipfix-export-per-sctp-stream-02, here are the 
        
conclusions:
    
* We were not too sure what is meant by "performance and 
        
capacity" in 
    
this context.
* If the question is about: What's the impact of additional SCTP 
streams in an existing session versus opening a new SCTP 
        
session? The 
    
impact is
minor:
- You have of course a message exchange to add the streams.
- You end up adding 16-24 bytes per stream.
- It is more lightweight to set up additional streams compared to 
setting up a new association.
The only thing that comes into my mind is throughput which
* If the question is about the throughput that could be 
        
impaired by 
    
processing overhead and message overhead.
- With respect of processing overhead, I have no idea how the 
utilization of a large number of streams influences the 
        
performance 
    
of the SCTP socket. I could imagine that a lot of state 
        
information 
    
must be stored.
- With respect of message overhead, we can say that the 
        
fact that we 
    
discourage multiplexing templates and data records of different 
template ids may lead to a larger message overhead.
If the data record rate is low for a specific template, 
        
the exporting 
    
process might not be able to optimally fill the IPFIX messages. 
Hence, we have more overhead due to additional IPFIX 
        
message headers 
    
and SCTP chunk headers.

Is this what you have in mind?

Regards, Benoit.

--------------050803040503060602030303-- From dromasca@avaya.com Sun Jun 21 05:42:13 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A063E3A6965 for ; Sun, 21 Jun 2009 05:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjqd3tiZ-Dw2 for ; Sun, 21 Jun 2009 05:42:12 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id A267B3A68E5 for ; Sun, 21 Jun 2009 05:42:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,262,1243828800"; d="scan'208,217";a="164925851" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 21 Jun 2009 08:42:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jun 2009 08:42:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F26D.ADFCA94C" Date: Sun, 21 Jun 2009 14:42:02 +0200 Message-ID: In-Reply-To: <4A3E282E.1050302@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity thread-index: AcnybD90xAzeNjPYRT2IYiKTxtwRIAAAUfDg References: <4A3805EC.3010702@cisco.com> <4A3C25E4.2040005@cisco.com> <4A3E282E.1050302@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 12:42:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F26D.ADFCA94C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The document was sent to IETF Last Call and the Last Call was issued on 6/16. Please wait until the Last Call expires (6/30) to make this change together with all other changes following last call comments.=20 =20 Regards, =20 Dan =20 ________________________________ From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Sunday, June 21, 2009 3:32 PM To: Romascanu, Dan (Dan) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] AD Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on performance and capacity =09 =09 Dan, =09 Thanks. I'll apply the changes What is the next step? You mentioned on your June 15th: =09 Please find below the AD review for draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature enough to go to IETF Last Call. Unless there are any special comments or concerns I will send it to IETF Last Call by tomorrow.=20 Do you want a quick updated version? =09 Regards, Benoit =09 =09 This looks fine to me. As an editorial observation, it is good to avoid 'personalized' style in such specifications like the usage of 'we' and 'the authors'. Impersonal modes are better.=20 =09 Thanks for addressing this comment.=20 =09 Dan =20 =09 =20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Saturday, June 20, 2009 2:57 AM To: Romascanu, Dan (Dan) Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20 (peterlei); Michael Tuexen Subject: Re: [IPFIX] AD Review of=20 draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 performance and capacity =09 Dan =20 Hi Benoit, =09 Yes, this is the type of information that I was looking for. My=20 reading of your answer is that the impact of adding SCTP=20 =20 streams in an=20 =20 existing session versus opening a new SCTP session is minor, with a=20 possible plus of efficiency at setup time. Processing overhead and=20 message overhead may potentially be a problem, and care should be=20 exercised in deployment in order to understand the effects. =09 Can we add corresponding text on this?=20 =20 =20 Here is our proposal: =09 What is the performance impact regarding the implementation=20 of these specifications compared to the IPFIX protocol [RFC5101]? =09 Although adding the new SCTP streams requires a message=20 exchange, it is more lightweight to set up additional SCTP=20 streams than to set up a new SCTP association since the only=20 overhead of adding stream(s) to an existing SCTP association=20 is the addition of 16-24 more bytes (allocated in the SCTP=20 association, a single time), whereas setting up a new SCTP=20 association implies more overhead. =09 In terms of of throughput impact, the fact that these=20 specifications discourage multiplexing Templates and Data=20 Records of different Template IDs may lead to a slightly=20 larger IPFIX Message overhead. If the Data Record rate is low=20 for a specific Template (hence a specific SCTP stream), the=20 Exporting Process might not be able to fill the IPFIX=20 Messages as fully as possible. In such a situation, we could=20 potentially have an overhead due to additional IPFIX Message=20 headers and SCTP chunk headers. =09 Finally, with respect to the processing overhead on the=20 Exporter, a lot of state information must be stored when a=20 large number of SCTP streams are used with an SCTP=20 association. The authors have not yet been able to compare=20 the performance impact of multiple streams within an SCTP=20 association versus opening the same number of independent=20 SCTP associations. =09 Fine with you? =09 Regards, Benoit. =20 Thanks and Regards, =09 Dan =09 =09 =20 =20 -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, June 16, 2009 11:52 PM To: Romascanu, Dan (Dan) Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20 =20 (peterlei);=20 =20 Michael Tuexen Subject: Re: [IPFIX] AD Review of =09 draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 =20 performance=20 =20 and capacity =09 Dan, =20 =20 Please find below the AD review for =09 draft-ietf-ipfix-export-per-sctp-stream-02. The document=20 =20 is mature=20 =20 enough to go to IETF Last Call. Unless there are any =20 =20 special comments =20 =20 or concerns I will send it to IETF Last Call by tomorrow. =09 Please consider the comments below together with the other =20 =20 IETF Last =20 =20 Call comments. The comments are divided into Technical=20 =20 and Editorial =20 T1. There is not information concerning the impact on =20 =20 performance and =20 =20 capacity of the reporting and collecting processes. Should =20 =20 we expect =20 =20 any considerable impact on performance and/or capacity? If any=20 implementation experience is available I would suggest that =20 =20 we record =20 =20 it. =20 =20 =20 Collecting information from the authors of=20 draft-stewart-tsvwg-sctpstrrst and=20 =09 draft-ietf-ipfix-export-per-sctp-stream-02, here are the=20 =20 conclusions: =20 * We were not too sure what is meant by "performance and=20 =20 capacity" in=20 =20 this context. * If the question is about: What's the impact of additional SCTP=20 streams in an existing session versus opening a new SCTP=20 =20 session? The=20 =20 impact is minor: - You have of course a message exchange to add the streams. - You end up adding 16-24 bytes per stream. - It is more lightweight to set up additional streams compared to=20 setting up a new association. The only thing that comes into my mind is throughput which * If the question is about the throughput that could be=20 =20 impaired by=20 =20 processing overhead and message overhead. - With respect of processing overhead, I have no idea how the=20 utilization of a large number of streams influences the=20 =20 performance=20 =20 of the SCTP socket. I could imagine that a lot of state=20 =20 information=20 =20 must be stored. - With respect of message overhead, we can say that the=20 =20 fact that we=20 =20 discourage multiplexing templates and data records of different=20 template ids may lead to a larger message overhead. If the data record rate is low for a specific template,=20 =20 the exporting=20 =20 process might not be able to optimally fill the IPFIX messages.=20 Hence, we have more overhead due to additional IPFIX=20 =20 message headers=20 =20 and SCTP chunk headers. =09 Is this what you have in mind? =09 Regards, Benoit. =09 =09 =20 =20 =20 ------_=_NextPart_001_01C9F26D.ADFCA94C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 document was sent to IETF Last Call and the Last Call was issued on = 6/16. Please=20 wait until the Last Call expires (6/30) to make this change together = with all=20 other changes following last call comments.
 
Regards,
 
Dan
 

From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Sunday, June 21, 2009 3:32 PM
To: = Romascanu, Dan=20 (Dan)
Cc: IETF IPFIX Working Group
Subject: Re: = [IPFIX] AD=20 Review of draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20 performance and capacity

Dan,

Thanks. I'll apply the changes
What is the = next=20 step?
You mentioned on your June 15th:
Please find below the AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document is mature
enough to go to IETF Last Call. Unless there are any special comments or
concerns I will send it to IETF Last Call by tomorrow. =
Do=20 you want a quick updated version?

Regards, Benoit

This looks fine to me. As an editorial =
observation, it is good to avoid
'personalized' style in such specifications like the usage of 'we' and
'the authors'. Impersonal modes are better.=20

Thanks for addressing this comment.=20

Dan
=20

  
-----Original Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]=20
Sent: Saturday, June 20, 2009 2:57 AM
To: Romascanu, Dan (Dan)
Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20
(peterlei); Michael Tuexen
Subject: Re: [IPFIX] AD Review of=20
draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20
performance and capacity

Dan
    
Hi Benoit,

Yes, this is the type of information that I was looking for. My=20
reading of your answer is that the impact of adding SCTP=20
      
streams in an=20
    
existing session versus =
opening a new SCTP session is minor, with a=20
possible plus of efficiency at setup time. Processing overhead and=20
message overhead may potentially be a problem, and care should be=20
exercised in deployment in order to understand the effects.

Can we add corresponding text on this?=20
 =20
      
Here is our proposal:

What is the performance impact regarding the implementation=20
of these specifications compared to the IPFIX protocol [RFC5101]?

Although adding the new SCTP streams requires a message=20
exchange, it is more lightweight to set up additional SCTP=20
streams than to set up a new SCTP association since the only=20
overhead of adding stream(s) to an existing SCTP association=20
is the addition of 16-24 more bytes (allocated in the SCTP=20
association, a single time), whereas setting up a new SCTP=20
association implies more overhead.

In terms of of throughput impact, the fact that these=20
specifications discourage multiplexing Templates and Data=20
Records of different Template IDs may lead to a slightly=20
larger IPFIX Message overhead. If the Data Record rate is low=20
for a specific Template (hence a specific SCTP stream), the=20
Exporting Process might not be able to fill the IPFIX=20
Messages as fully as possible. In such a situation, we could=20
potentially have an overhead due to additional IPFIX Message=20
headers and SCTP chunk headers.

Finally, with respect to the processing overhead on the=20
Exporter, a lot of state information must be stored when a=20
large number of SCTP streams are used with an SCTP=20
association. The authors have not yet been able to compare=20
the performance impact of multiple streams within an SCTP=20
association versus opening the same number of independent=20
SCTP associations.

Fine with you?

Regards, Benoit.
    
Thanks and Regards,

Dan


 =20
      
-----Original =
Message-----
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, June 16, 2009 11:52 PM
To: Romascanu, Dan (Dan)
Cc: IETF IPFIX Working Group; Randall Stewart; Peter Lei=20
        
(peterlei);=20
    
Michael Tuexen
Subject: Re: [IPFIX] AD Review of
draft-ietf-ipfix-export-per-sctp-stream-02 -> impact on=20
        
performance=20
    
and capacity

Dan,
   =20
        
Please find below the =
AD review for
draft-ietf-ipfix-export-per-sctp-stream-02. The document=20
          
is =
mature=20
    
enough to go to IETF =
Last Call. Unless there are any
     =20
          
special comments
   =20
        
or concerns I will =
send it to IETF Last Call by tomorrow.

Please consider the comments below together with the other
     =20
          
IETF Last
   =20
        
Call comments. The =
comments are divided into Technical=20
          
and Editorial
    
T1. There is not =
information concerning the impact on
     =20
          
performance and
   =20
        
capacity of the =
reporting and collecting processes. Should
     =20
          
we expect
   =20
        
any considerable =
impact on performance and/or capacity? If any=20
implementation experience is available I would suggest that
     =20
          
we record
   =20
        
it.
 =20
     =20
          
Collecting information from =
the authors of=20
draft-stewart-tsvwg-sctpstrrst and=20
draft-ietf-ipfix-export-per-sctp-stream-02, here are the=20
        
conclusions:
    
* We were not too sure =
what is meant by "performance and=20
        
capacity" in=20
    
this context.
* If the question is about: What's the impact of additional SCTP=20
streams in an existing session versus opening a new SCTP=20
        
session? The=20
    
impact is
minor:
- You have of course a message exchange to add the streams.
- You end up adding 16-24 bytes per stream.
- It is more lightweight to set up additional streams compared to=20
setting up a new association.
The only thing that comes into my mind is throughput which
* If the question is about the throughput that could be=20
        
impaired by=20
    
processing overhead and =
message overhead.
- With respect of processing overhead, I have no idea how the=20
utilization of a large number of streams influences the=20
        
performance=20
    
of the SCTP socket. I =
could imagine that a lot of state=20
        
information=20
    
must be stored.
- With respect of message overhead, we can say that the=20
        
fact that we=20
    
discourage multiplexing =
templates and data records of different=20
template ids may lead to a larger message overhead.
If the data record rate is low for a specific template,=20
        
the exporting=20
    
process might not be =
able to optimally fill the IPFIX messages.=20
Hence, we have more overhead due to additional IPFIX=20
        
message headers=20
    
and SCTP chunk headers.

Is this what you have in mind?

Regards, Benoit.


   =20
        
    =

------_=_NextPart_001_01C9F26D.ADFCA94C-- From trammell@tik.ee.ethz.ch Mon Jun 22 03:56:39 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1391A3A699D for ; Mon, 22 Jun 2009 03:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 N0bqjcxfUPlD for ; Mon, 22 Jun 2009 03:56:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5F7833A6960 for ; Mon, 22 Jun 2009 03:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EB557D936B; Mon, 22 Jun 2009 12:56:50 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Gcwztt+QpebM; Mon, 22 Jun 2009 12:56:50 +0200 (MEST) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id A5788D9307; Mon, 22 Jun 2009 12:56:50 +0200 (MEST) Message-Id: <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> From: Brian Trammell To: Gerhard Muenz In-Reply-To: <4A3BF0B4.20104@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 22 Jun 2009 12:56:50 +0200 References: <20090618161432.B5C8.17391CF2@nttv6.net> <4A3BF0B4.20104@net.in.tum.de> X-Mailer: Apple Mail (2.935.3) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 10:56:39 -0000 Gerhard, Inline. On Jun 19, 2009, at 10:10 PM, Gerhard Muenz wrote: > > Brian, > > I'm not sure if we need all this information in the terminology =20 > section. > Maybe, there is a better place them, either in another section of the > draft or in the framework draft. This is a different argument, which we seem to be converging in the =20 direction of defining everything consistently twice, and allowing the =20= problem statement to use the "real" terminology in its example. There =20= are of course valid reasons not to do this, as well. I'm not sold =20 either way, I'm just trying to follow consensus; if this is what we =20 want in the terminology, then this is what it should look like. I'm not at all certain that the Intermediate FOO Process definitions =20 are necessary, but they do underscore that _devices_ we seem to have =20 already defined are really just hosts for processes, and that =20 processes are the important part. > BTW, there are several problems with your definitions. See inline. Thanks for the comments; comments thereon below. :) > Regards, > Gerhard > > Brian Trammell wrote: >> I propose the following unified terminology section, following the >> thread to date: >> >> IPFIX Mediation describes the manipulation and conversion of records >> exported using IPFIX, by applying mediation functions within one or =20= >> more > > "exported using IPFIX" should be removed, because they could have been > exported using Netflow. Negative, although I agree the phrasing is confusing here... What I =20 meant was, the _output_ of mediation is necessarily and by definition =20= IPFIX. In full, the correction should read as follows: IPFIX Mediation describes the manipulation, conversion, and export of =20= records via IPFIX, by applying mediation functions within one or more =20= Intermediate Processes to a stream of records in an IPFIX Mediator. =20 The following terms are used in this document to describe the =20 architectural entities used by IPFIX Mediation. >> Intemediate Process >> >> An Intermediate Process takes a sequence of records from a Collecting >> Process, IPFIX File Reader, or another Intermediate Process within a > > The Metering Process is missing as a source of records. I wonder if we > have to specify the sources at all. Point. >> Mediator; performs some transformation on these records based upon =20= >> the >> content of the records themselves, state kept across multiple =20 >> records, >> configuration parameters, or other data; and passes a sequence of >> transformed records on to an Exporting Process, IPFIX File Writer, or >> another Intermediate Process within a Mediator. This document =20 >> describes > > Again, do we have to specify the sinks here? I think so; I've tried constructing this definition without source/=20 sink specifications and it sounds so general that it doesn't actually =20= say anything at all. >> specific Intermediate Processes below used in the elaboration of the >> problem statement; however, this is not an exhaustive list. Corrected: Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate =20= Process within a Mediator; performs some transformation on these =20 records based upon the content of the records themselves, state kept across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process within a Mediator. This document describes specific Intermediate Processes below used in the elaboration of the problem statement; however, this is not an exhaustive list. >> Intermediate Aggregation Process >> >> An Intermediate Aggregation Process is an Intermediate Process that >> aggregates records based upon a new set of Flow Key fields, or =20 >> functions >> applied to Flow Key fields (e.g. binning, subnet aggregation). > > It is also possible to aggregate PSAMP Packet Reports that do not have > Flow Keys! So, we cannot assume that the original records have flow =20= > key > fields. Point, however, aggregation by necessity requires some "keys" on which =20= to aggregate. So we can use lowercase "keys" (which I acknowledge =20 risks confusing people... are keys Flow Keys?, but it's better than =20 nothing.) An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a set of key fields, or functions applied to fields from the record (e.g. binning, subnet aggregation). >> Intermediate Correlation Process >> >> An Intermediate Correlation Process is an Intermediate Process which >> adds information to records noting correlations among them, or =20 >> generates >> new records with correlated data from multiple records (e.g. the >> production of bidirectional flow records from unidirectional flow =20 >> records). >> >> Intermediate Selection Process >> >> An Intermediate Selection Process is an Intermediate Process that >> selects records from a sequence based upon criteria evaluated record >> values, and passes only those records that match the criteria (e.g. >> filtering only records from a given network to a given Collector). >> >> Intermediate Anonymisation Process >> >> An Intermediate Anonymisation Process is an Intermediate Process that >> transforms records in order to anonymise them, to protect the =20 >> identity >> of the entities described by the records (e.g. by applying >> prefix-preserving pseudonymisation of IP addresses). (see above re: maybe we don't need these here.) >> IPFIX Mediator >> >> An IPFIX Mediator is an IPFIX Device that provides mediation >> capabilities by receiving records from some data source, hosting =20 >> zero or >> more Intermediate Processes to transform those records, and exporting >> those records in IPFIX Messages via an Exporting Process. In the =20 >> common >> case, a Mediator receives records from a Collecting Process, but =20 >> could > > What about records from a Metering Process? Does a Mediator actually receive records directly from an MP, or is an =20= MP->IP->CP box something different? I don't have an opinion here =20 (well, I do, but it's a mild one)... it just seems like something that =20= hasn't been thought out yet, and should be. >> also receive records from data sources not encoded using IPFIX, =20 >> e.g., in >> the case of NetFlow V9 protocol translation. Specific types of =20 >> Mediators >> are defined below; some of these reference original mediation >> capabilities defined in earlier IPFIX documens before the =20 >> elaboration of >> the Mediator problem statement. >> >> IPFIX Proxy >> >> An IPFIX Proxy is an IPFIX Mediator that relays incoming >> IPFIX Messages or messages in other protocols to one or more =20 >> Collectors. >> It can provide transport protocol mediation and re-encoding. >> >> IPFIX Concentrator >> >> An IPFIX Concentrator is an IPFIX Mediator that recieves data from =20= >> one >> or more Exporters and sends them to a single Collector, optionally >> transforming the records using zero or more Intermediate Processes on >> the way. >> >> IPFIX Distributor >> >> An IPFIX Distributor is an IPFIX Mediator that recieves data from =20 >> one or >> more Exporters and sends them to one or more Collectors, deciding =20 >> which >> Collector(s) to send each record to based upon the decision of an >> Intermediate Selection Process. >> >> IPFIX Masquerading Proxy >> >> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data =20= >> from >> one or more Exporters and sends them to a single Collector, using =20 >> one or >> more Intermediate Aggregation Functions and Intermediate =20 >> Anonymisation >> Functions to screen out parts of records according to configured >> policies, in order to protect the privacy of the network's end =20 >> users or >> senstive data of the exporting organization. >> >> >> Best regards, >> >> Brian >> _______________________________________________ >> 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 > > From muenz@net.in.tum.de Mon Jun 22 04:50:34 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F3B3A6DD5 for ; Mon, 22 Jun 2009 04:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-0.266, 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 C0CD2upHskmS for ; Mon, 22 Jun 2009 04:50:33 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 22ED63A6961 for ; Mon, 22 Jun 2009 04:50:32 -0700 (PDT) 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 6EA8348317; Mon, 22 Jun 2009 13:50:46 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 541D026E5; Mon, 22 Jun 2009 13:50:46 +0200 (CEST) Message-ID: <4A3F706F.5020602@net.in.tum.de> Date: Mon, 22 Jun 2009 13:52:15 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Brian Trammell References: <20090618161432.B5C8.17391CF2@nttv6.net> <4A3BF0B4.20104@net.in.tum.de> <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> In-Reply-To: <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010404070400070007030807" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 11:50:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010404070400070007030807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian, Comments inline. Brian Trammell wrote: >> I'm not sure if we need all this information in the terminology sectio= n. >> Maybe, there is a better place them, either in another section of the >> draft or in the framework draft. >=20 > This is a different argument, which we seem to be converging in the > direction of defining everything consistently twice, and allowing the > problem statement to use the "real" terminology in its example. There > are of course valid reasons not to do this, as well. I'm not sold eithe= r > way, I'm just trying to follow consensus; if this is what we want in th= e > terminology, then this is what it should look like. >=20 > I'm not at all certain that the Intermediate FOO Process definitions ar= e > necessary, but they do underscore that _devices_ we seem to have alread= y > defined are really just hosts for processes, and that processes are the= > important part. >=20 >> BTW, there are several problems with your definitions. See inline. >=20 > Thanks for the comments; comments thereon below. :) >=20 >> Regards, >> Gerhard >> >> Brian Trammell wrote: >>> I propose the following unified terminology section, following the >>> thread to date: >>> >>> IPFIX Mediation describes the manipulation and conversion of records >>> exported using IPFIX, by applying mediation functions within one or m= ore >> >> "exported using IPFIX" should be removed, because they could have been= >> exported using Netflow. >=20 > Negative, although I agree the phrasing is confusing here...=20 Indeed. I (mis)understood the phrase in a way that other people could to as well ;) > What I > meant was, the _output_ of mediation is necessarily and by definition Agreed. > IPFIX. In full, the correction should read as follows: >=20 > IPFIX Mediation describes the manipulation, conversion, and export of > records via IPFIX, by applying mediation functions within one or more > Intermediate Processes to a stream of records in an IPFIX Mediator. The= > following terms are used in this document to describe the architectural= > entities used by IPFIX Mediation. I do not think that IPFIX Mediation "describes" the export of records. I would change your original text in something like: "IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions ..." >>> Intemediate Process >>> >>> An Intermediate Process takes a sequence of records from a Collecting= >>> Process, IPFIX File Reader, or another Intermediate Process within a >> >> The Metering Process is missing as a source of records. I wonder if we= >> have to specify the sources at all. >=20 > Point. >=20 >>> Mediator; performs some transformation on these records based upon th= e >>> content of the records themselves, state kept across multiple records= , >>> configuration parameters, or other data; and passes a sequence of >>> transformed records on to an Exporting Process, IPFIX File Writer, or= >>> another Intermediate Process within a Mediator. This document describ= es >> >> Again, do we have to specify the sinks here? >=20 > I think so; I've tried constructing this definition without source/sink= > specifications and it sounds so general that it doesn't actually say > anything at all. >=20 >>> specific Intermediate Processes below used in the elaboration of the >>> problem statement; however, this is not an exhaustive list. >=20 > Corrected: >=20 > Intermediate Process >=20 > An Intermediate Process takes a sequence of records from a Collecting > Process, Metering Process, IPFIX File Reader, or another Intermediate > Process within a Mediator; performs some transformation on these record= s > based upon the > content of the records themselves, state kept across multiple records, > configuration parameters, or other data; and passes a sequence of > transformed records on to an Exporting Process, IPFIX File Writer, or > another Intermediate Process within a Mediator. This document describes= > specific Intermediate Processes below used in the elaboration of the > problem statement; however, this is not an exhaustive list. Nice. >>> Intermediate Aggregation Process >>> >>> An Intermediate Aggregation Process is an Intermediate Process that >>> aggregates records based upon a new set of Flow Key fields, or functi= ons >>> applied to Flow Key fields (e.g. binning, subnet aggregation). >> >> It is also possible to aggregate PSAMP Packet Reports that do not have= >> Flow Keys! So, we cannot assume that the original records have flow ke= y >> fields. >=20 > Point, however, aggregation by necessity requires some "keys" on which > to aggregate. So we can use lowercase "keys" (which I acknowledge risks= > confusing people... are keys Flow Keys?, but it's better than nothing.)= >=20 > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a set of key fields, or functions > applied to fields from the record (e.g. binning, subnet aggregation). In the first paraphrase of the original text, there is no problem with "Flow Keys" as they may come from the configuration of the IP: An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a set of Flow Keys, or functions applied to fields from the record (e.g. binning, subnet aggregation). >>> Intermediate Correlation Process >>> >>> An Intermediate Correlation Process is an Intermediate Process which >>> adds information to records noting correlations among them, or genera= tes >>> new records with correlated data from multiple records (e.g. the >>> production of bidirectional flow records from unidirectional flow >>> records). >>> >>> Intermediate Selection Process >>> >>> An Intermediate Selection Process is an Intermediate Process that >>> selects records from a sequence based upon criteria evaluated record >>> values, and passes only those records that match the criteria (e.g. >>> filtering only records from a given network to a given Collector). >>> >>> Intermediate Anonymisation Process >>> >>> An Intermediate Anonymisation Process is an Intermediate Process that= >>> transforms records in order to anonymise them, to protect the identit= y >>> of the entities described by the records (e.g. by applying >>> prefix-preserving pseudonymisation of IP addresses). >=20 > (see above re: maybe we don't need these here.) >=20 >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some data source, hosting zero= or >>> more Intermediate Processes to transform those records, and exporting= >>> those records in IPFIX Messages via an Exporting Process. In the comm= on >>> case, a Mediator receives records from a Collecting Process, but coul= d >> >> What about records from a Metering Process? >=20 > Does a Mediator actually receive records directly from an MP, or is an > MP->IP->CP box something different? I don't have an opinion here (well,= Do you mean MP->IP->EP ? > I do, but it's a mild one)... it just seems like something that hasn't > been thought out yet, and should be. Hm, I think we have already thought about it. According to the definition, an IPFIX Mediator includes at least one IP and one EP (because it is an IPFIX Device). So, MP->IP->EP is an IPFIX Mediator by definition. Gerhard >>> also receive records from data sources not encoded using IPFIX, e.g.,= in >>> the case of NetFlow V9 protocol translation. Specific types of Mediat= ors >>> are defined below; some of these reference original mediation >>> capabilities defined in earlier IPFIX documens before the elaboration= of >>> the Mediator problem statement. >>> >>> IPFIX Proxy >>> >>> An IPFIX Proxy is an IPFIX Mediator that relays incoming >>> IPFIX Messages or messages in other protocols to one or more Collecto= rs. >>> It can provide transport protocol mediation and re-encoding. >>> >>> IPFIX Concentrator >>> >>> An IPFIX Concentrator is an IPFIX Mediator that recieves data from on= e >>> or more Exporters and sends them to a single Collector, optionally >>> transforming the records using zero or more Intermediate Processes on= >>> the way. >>> >>> IPFIX Distributor >>> >>> An IPFIX Distributor is an IPFIX Mediator that recieves data from one= or >>> more Exporters and sends them to one or more Collectors, deciding whi= ch >>> Collector(s) to send each record to based upon the decision of an >>> Intermediate Selection Process. >>> >>> IPFIX Masquerading Proxy >>> >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data f= rom >>> one or more Exporters and sends them to a single Collector, using one= or >>> more Intermediate Aggregation Functions and Intermediate Anonymisatio= n >>> Functions to screen out parts of records according to configured >>> policies, in order to protect the privacy of the network's end users = or >>> senstive data of the exporting organization. >>> >>> >>> Best regards, >>> >>> Brian >>> _______________________________________________ >>> 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 --------------ms010404070400070007030807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjIyMTE1MjE1WjAjBgkqhkiG9w0BCQQxFgQU BR5xE+Odmt2P7DdhrIiSIoMPpWMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAJFnHf/E0r+Z9Xo6WL4QFd2nJVovXuIrjlsa1jW2YcTOB2vp HMt1TnD6soKTRisIjIzNDVm8SgagLiqRyPpP4lm6C8yIUYc4uSOYPEplxn0PaRhE7pVQKJJh iV1JlsSfN4sLTKbry+EtSuj8rJX4OhhuLquqYaFFkJZRjY6dVvTP/iv8bYjI+XGF0fSC9eXU T2jO1gU3sz2bVPrJcrgDxEkDvcdCby+tRkz3qAhg3gtw44adOBeO6yS2XOMBtQ4ytSO5CnRU rS2aEN6r1gBKrLileI2nrJt81cyGgJL6MmN5xoTPALvs4ZESvnn22tQiM/iNfGbY+uG6Nl/7 h+4v/LoAAAAAAAA= --------------ms010404070400070007030807-- From akoba@orange.plala.or.jp Mon Jun 22 10:39:00 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098FC3A6BDB for ; Mon, 22 Jun 2009 10:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnsREHy9Q3CI for ; Mon, 22 Jun 2009 10:38:58 -0700 (PDT) Received: from msa01b.plala.or.jp (msa01.plala.or.jp [58.93.240.1]) by core3.amsl.com (Postfix) with ESMTP id 328863A6B51 for ; Mon, 22 Jun 2009 10:38:57 -0700 (PDT) Received: from [127.0.0.1] (really [118.21.13.32]) by msa01b.plala.or.jp with ESMTP id <20090622173911.KKPM18533.msa01b.plala.or.jp@[127.0.0.1]>; Tue, 23 Jun 2009 02:39:11 +0900 Date: Tue, 23 Jun 2009 02:39:12 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A3F706F.5020602@net.in.tum.de> References: <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> <4A3F706F.5020602@net.in.tum.de> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.068 Message-Id: <20090623012914.FC4B.AKOBA@orange.plala.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-VirusScan: Outbound; msa01b; Tue, 23 Jun 2009 02:39:11 +0900 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 17:39:00 -0000 Hi Gerhard, Brian, On Mon, 22 Jun 2009 13:52:15 +0200 Gerhard Muenz wrote: > > Brian, > > Comments inline. > > Brian Trammell wrote: > >> I'm not sure if we need all this information in the terminology section. > >> Maybe, there is a better place them, either in another section of the > >> draft or in the framework draft. > > > > This is a different argument, which we seem to be converging in the > > direction of defining everything consistently twice, and allowing the > > problem statement to use the "real" terminology in its example. There > > are of course valid reasons not to do this, as well. I'm not sold either > > way, I'm just trying to follow consensus; if this is what we want in the > > terminology, then this is what it should look like. > > > > I'm not at all certain that the Intermediate FOO Process definitions are > > necessary, but they do underscore that _devices_ we seem to have already > > defined are really just hosts for processes, and that processes are the > > important part. > > > >> BTW, there are several problems with your definitions. See inline. > > > > Thanks for the comments; comments thereon below. :) > > > >> Regards, > >> Gerhard > >> > >> Brian Trammell wrote: > >>> I propose the following unified terminology section, following the > >>> thread to date: > >>> > >>> IPFIX Mediation describes the manipulation and conversion of records > >>> exported using IPFIX, by applying mediation functions within one or more > >> > >> "exported using IPFIX" should be removed, because they could have been > >> exported using Netflow. > > > > Negative, although I agree the phrasing is confusing here... > > Indeed. I (mis)understood the phrase in a way that other people could to > as well ;) > Me, too. :) > > What I > > meant was, the _output_ of mediation is necessarily and by definition > > Agreed. > > > IPFIX. In full, the correction should read as follows: > > > > IPFIX Mediation describes the manipulation, conversion, and export of > > records via IPFIX, by applying mediation functions within one or more > > Intermediate Processes to a stream of records in an IPFIX Mediator. The > > following terms are used in this document to describe the architectural > > entities used by IPFIX Mediation. Brian, let me know your definition in detail. Your definition looks like IPFIX Mediation is only implemented in IPFIX Mediator. IPFIX Mediation, that is Intermediate Processes, can be hosted in any device. And IPFIX Mediation definition refers to IPFIX Mediator, and IPFIX Mediator definition refers to mediation function. It seems a little bit strange for me. Or can you remove "in an IPFIX Mediator"? > > I do not think that IPFIX Mediation "describes" the export of records. > I would change your original text in something like: > > "IPFIX Mediation describes the manipulation and conversion of records > for subsequent export using IPFIX, by applying mediation functions ..." > Gerhard, the above definition say that finally IPFIX exporting after executing IPFIX Mediation is implemented. Is it right? If Intermediate Process is hosted in NMS or Collector, this device would not export IPFIX. My original definition is as follows. IPFIX Mediation IPFIX Mediation is a generic function that covers the manipulation of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX Messages, or their transmission. The IPFIX Mediation offers one or multiple of the following capabilities: I would like to edit as follows. "IPFIX Mediation describes the manipulation and conversion of records or IPFIX Message, by applying..." > >>> Intemediate Process > >>> > >>> An Intermediate Process takes a sequence of records from a Collecting > >>> Process, IPFIX File Reader, or another Intermediate Process within a > >> > >> The Metering Process is missing as a source of records. I wonder if we > >> have to specify the sources at all. > > > > Point. > > > >>> Mediator; performs some transformation on these records based upon the > >>> content of the records themselves, state kept across multiple records, > >>> configuration parameters, or other data; and passes a sequence of > >>> transformed records on to an Exporting Process, IPFIX File Writer, or > >>> another Intermediate Process within a Mediator. This document describes > >> > >> Again, do we have to specify the sinks here? > > > > I think so; I've tried constructing this definition without source/sink > > specifications and it sounds so general that it doesn't actually say > > anything at all. > > > >>> specific Intermediate Processes below used in the elaboration of the > >>> problem statement; however, this is not an exhaustive list. > > > > Corrected: > > > > Intermediate Process > > > > An Intermediate Process takes a sequence of records from a Collecting > > Process, Metering Process, IPFIX File Reader, or another Intermediate > > Process within a Mediator; performs some transformation on these records > > based upon the > > content of the records themselves, state kept across multiple records, > > configuration parameters, or other data; and passes a sequence of Configuration parameter is good idea. > > transformed records on to an Exporting Process, IPFIX File Writer, or > > another Intermediate Process within a Mediator. This document describes > > specific Intermediate Processes below used in the elaboration of the > > problem statement; however, this is not an exhaustive list. > > Nice. > > >>> Intermediate Aggregation Process > >>> > >>> An Intermediate Aggregation Process is an Intermediate Process that > >>> aggregates records based upon a new set of Flow Key fields, or functions > >>> applied to Flow Key fields (e.g. binning, subnet aggregation). > >> > >> It is also possible to aggregate PSAMP Packet Reports that do not have > >> Flow Keys! So, we cannot assume that the original records have flow key > >> fields. > > > > Point, however, aggregation by necessity requires some "keys" on which > > to aggregate. So we can use lowercase "keys" (which I acknowledge risks > > confusing people... are keys Flow Keys?, but it's better than nothing.) > > > > An Intermediate Aggregation Process is an Intermediate Process that > > aggregates records based upon a set of key fields, or functions > > applied to fields from the record (e.g. binning, subnet aggregation). > > In the first paraphrase of the original text, there is no problem with > "Flow Keys" as they may come from the configuration of the IP: > > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a set of Flow Keys, or functions > applied to fields from the record (e.g. binning, subnet aggregation). > Um.., problem statement and framework proposes "spatial composition". In that case, Exporter IP address, or Observation Domain ID, or some identifier based on observation information becomes key fields, thus, original Flow Records does not includes Flow Key fields. I am not sure the definition can cover the spatial composition. > >>> Intermediate Correlation Process > >>> > >>> An Intermediate Correlation Process is an Intermediate Process which > >>> adds information to records noting correlations among them, or generates > >>> new records with correlated data from multiple records (e.g. the > >>> production of bidirectional flow records from unidirectional flow > >>> records). > >>> > >>> Intermediate Selection Process > >>> > >>> An Intermediate Selection Process is an Intermediate Process that > >>> selects records from a sequence based upon criteria evaluated record > >>> values, and passes only those records that match the criteria (e.g. > >>> filtering only records from a given network to a given Collector). > >>> > >>> Intermediate Anonymisation Process > >>> > >>> An Intermediate Anonymisation Process is an Intermediate Process that > >>> transforms records in order to anonymise them, to protect the identity > >>> of the entities described by the records (e.g. by applying > >>> prefix-preserving pseudonymisation of IP addresses). > > > > (see above re: maybe we don't need these here.) > > > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>> capabilities by receiving records from some data source, hosting zero or > >>> more Intermediate Processes to transform those records, and exporting > >>> those records in IPFIX Messages via an Exporting Process. In the common > >>> case, a Mediator receives records from a Collecting Process, but could > >> > >> What about records from a Metering Process? > > > > Does a Mediator actually receive records directly from an MP, or is an > > MP->IP->CP box something different? I don't have an opinion here (well, > > Do you mean MP->IP->EP ? > > > I do, but it's a mild one)... it just seems like something that hasn't > > been thought out yet, and should be. > > Hm, I think we have already thought about it. > According to the definition, an IPFIX Mediator includes at least one IP > and one EP (because it is an IPFIX Device). So, MP->IP->EP is an IPFIX > Mediator by definition. > I agreed. Regards, Atsushi From muenz@net.in.tum.de Mon Jun 22 11:07:17 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3514028C25E for ; Mon, 22 Jun 2009 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 R1Rrx6g4Jovd for ; Mon, 22 Jun 2009 11:07:15 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 03A4B28C25B for ; Mon, 22 Jun 2009 11:07:15 -0700 (PDT) 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 EECBE48317; Mon, 22 Jun 2009 20:07:28 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id D3D4126E5; Mon, 22 Jun 2009 20:07:28 +0200 (CEST) Message-ID: <4A3FC8BA.4010708@net.in.tum.de> Date: Mon, 22 Jun 2009 20:08:58 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> <4A3F706F.5020602@net.in.tum.de> <20090623012914.FC4B.AKOBA@orange.plala.or.jp> In-Reply-To: <20090623012914.FC4B.AKOBA@orange.plala.or.jp> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070509010307060002010202" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:07:17 -0000 This is a cryptographically signed message in MIME format. --------------ms070509010307060002010202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: >> Brian Trammell wrote: >>>> I'm not sure if we need all this information in the terminology sect= ion. >>>> Maybe, there is a better place them, either in another section of th= e >>>> draft or in the framework draft. >>> This is a different argument, which we seem to be converging in the >>> direction of defining everything consistently twice, and allowing the= >>> problem statement to use the "real" terminology in its example. There= >>> are of course valid reasons not to do this, as well. I'm not sold eit= her >>> way, I'm just trying to follow consensus; if this is what we want in = the >>> terminology, then this is what it should look like. >>> >>> I'm not at all certain that the Intermediate FOO Process definitions = are >>> necessary, but they do underscore that _devices_ we seem to have alre= ady >>> defined are really just hosts for processes, and that processes are t= he >>> important part. >>> >>>> BTW, there are several problems with your definitions. See inline. >>> Thanks for the comments; comments thereon below. :) >>> >>>> Regards, >>>> Gerhard >>>> >>>> Brian Trammell wrote: >>>>> I propose the following unified terminology section, following the >>>>> thread to date: >>>>> >>>>> IPFIX Mediation describes the manipulation and conversion of record= s >>>>> exported using IPFIX, by applying mediation functions within one or= more >>>> "exported using IPFIX" should be removed, because they could have be= en >>>> exported using Netflow. >>> Negative, although I agree the phrasing is confusing here...=20 >> Indeed. I (mis)understood the phrase in a way that other people could = to >> as well ;) >> > Me, too. :) >=20 >>> What I >>> meant was, the _output_ of mediation is necessarily and by definition= >> Agreed. >> >>> IPFIX. In full, the correction should read as follows: >>> >>> IPFIX Mediation describes the manipulation, conversion, and export of= >>> records via IPFIX, by applying mediation functions within one or more= >>> Intermediate Processes to a stream of records in an IPFIX Mediator. T= he >>> following terms are used in this document to describe the architectur= al >>> entities used by IPFIX Mediation. >=20 > Brian, let me know your definition in detail. > Your definition looks like IPFIX Mediation is only implemented in IPFIX= > Mediator. IPFIX Mediation, that is Intermediate Processes, can be hoste= d > in any device.=20 >=20 > And IPFIX Mediation definition refers to IPFIX Mediator, and IPFIX > Mediator definition refers to mediation function. It seems a little bit= > strange for me. >=20 > Or can you remove "in an IPFIX Mediator"?=20 >=20 >> I do not think that IPFIX Mediation "describes" the export of records.= >> I would change your original text in something like: >> >> "IPFIX Mediation describes the manipulation and conversion of records >> for subsequent export using IPFIX, by applying mediation functions ...= " >> >=20 > Gerhard, the above definition say that finally IPFIX exporting after > executing IPFIX Mediation is implemented. Is it right? If Intermediate > Process is hosted in NMS or Collector, this device would not export > IPFIX. I'm not sure if we should consider IPFIX Mediation hosted in NMS aka Collectors that do not reexport the data afterwards. Of course, NMS/Collectors typically analyze the received data, and the analysis functions can be the same as in an IP. However, we do not need to standardize what happens here because the data is not exported any mor= e. I do not think that we should standardize how IPFIX data is treated beyond the Collector. > My original definition is as follows. >=20 > IPFIX Mediation >=20 > IPFIX Mediation is a generic function that covers the manipulatio= n > of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX > Messages, or their transmission. The IPFIX Mediation offers one > or multiple of the following capabilities: >=20 > I would like to edit as follows. >=20 > "IPFIX Mediation describes the manipulation and conversion of records o= r IPFIX > Message, by applying..." If this is consensus, I would not oppose it. However, if you look at this: IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages--> then, the IP does not see/treat any IPFIX messages, just records. >>>>> Intemediate Process >>>>> >>>>> An Intermediate Process takes a sequence of records from a Collecti= ng >>>>> Process, IPFIX File Reader, or another Intermediate Process within = a >>>> The Metering Process is missing as a source of records. I wonder if = we >>>> have to specify the sources at all. >>> Point. >>> >>>>> Mediator; performs some transformation on these records based upon = the >>>>> content of the records themselves, state kept across multiple recor= ds, >>>>> configuration parameters, or other data; and passes a sequence of >>>>> transformed records on to an Exporting Process, IPFIX File Writer, = or >>>>> another Intermediate Process within a Mediator. This document descr= ibes >>>> Again, do we have to specify the sinks here? >>> I think so; I've tried constructing this definition without source/si= nk >>> specifications and it sounds so general that it doesn't actually say >>> anything at all. >>> >>>>> specific Intermediate Processes below used in the elaboration of th= e >>>>> problem statement; however, this is not an exhaustive list. >>> Corrected: >>> >>> Intermediate Process >>> >>> An Intermediate Process takes a sequence of records from a Collecting= >>> Process, Metering Process, IPFIX File Reader, or another Intermediate= >>> Process within a Mediator; performs some transformation on these reco= rds >>> based upon the >>> content of the records themselves, state kept across multiple records= , >>> configuration parameters, or other data; and passes a sequence of >=20 > Configuration parameter is good idea. >=20 >>> transformed records on to an Exporting Process, IPFIX File Writer, or= >>> another Intermediate Process within a Mediator. This document describ= es >>> specific Intermediate Processes below used in the elaboration of the >>> problem statement; however, this is not an exhaustive list. >> Nice. >> >>>>> Intermediate Aggregation Process >>>>> >>>>> An Intermediate Aggregation Process is an Intermediate Process that= >>>>> aggregates records based upon a new set of Flow Key fields, or func= tions >>>>> applied to Flow Key fields (e.g. binning, subnet aggregation). >>>> It is also possible to aggregate PSAMP Packet Reports that do not ha= ve >>>> Flow Keys! So, we cannot assume that the original records have flow = key >>>> fields. >>> Point, however, aggregation by necessity requires some "keys" on whic= h >>> to aggregate. So we can use lowercase "keys" (which I acknowledge ris= ks >>> confusing people... are keys Flow Keys?, but it's better than nothing= =2E) >>> >>> An Intermediate Aggregation Process is an Intermediate Process that >>> aggregates records based upon a set of key fields, or functions >>> applied to fields from the record (e.g. binning, subnet aggregation).= >> In the first paraphrase of the original text, there is no problem with= >> "Flow Keys" as they may come from the configuration of the IP: >> >> An Intermediate Aggregation Process is an Intermediate Process that >> aggregates records based upon a set of Flow Keys, or functions >> applied to fields from the record (e.g. binning, subnet aggregation). >> >=20 > Um.., problem statement and framework proposes "spatial composition". I= n > that case, Exporter IP address, or Observation Domain ID, or some > identifier based on observation information becomes key fields, thus, > original Flow Records does not includes Flow Key fields. I am not sure > the definition can cover the spatial composition. I do not understand where the problem should be. In my opinion, the output of the aggregation process is a stream of Flow Records. These Flow Records have Flow Keys. These Flow Keys do not have to be the same as those potentially included in the records that entered the aggregation process. My definition does not mention, where the Flow Keys come from. I would suggest that they typically come from configuration. Regards, Gerhard >>>>> Intermediate Correlation Process >>>>> >>>>> An Intermediate Correlation Process is an Intermediate Process whic= h >>>>> adds information to records noting correlations among them, or gene= rates >>>>> new records with correlated data from multiple records (e.g. the >>>>> production of bidirectional flow records from unidirectional flow >>>>> records). >>>>> >>>>> Intermediate Selection Process >>>>> >>>>> An Intermediate Selection Process is an Intermediate Process that >>>>> selects records from a sequence based upon criteria evaluated recor= d >>>>> values, and passes only those records that match the criteria (e.g.= >>>>> filtering only records from a given network to a given Collector). >>>>> >>>>> Intermediate Anonymisation Process >>>>> >>>>> An Intermediate Anonymisation Process is an Intermediate Process th= at >>>>> transforms records in order to anonymise them, to protect the ident= ity >>>>> of the entities described by the records (e.g. by applying >>>>> prefix-preserving pseudonymisation of IP addresses). >>> (see above re: maybe we don't need these here.) >>> >>>>> IPFIX Mediator >>>>> >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>> capabilities by receiving records from some data source, hosting ze= ro or >>>>> more Intermediate Processes to transform those records, and exporti= ng >>>>> those records in IPFIX Messages via an Exporting Process. In the co= mmon >>>>> case, a Mediator receives records from a Collecting Process, but co= uld >>>> What about records from a Metering Process? >>> Does a Mediator actually receive records directly from an MP, or is a= n >>> MP->IP->CP box something different? I don't have an opinion here (wel= l, >> Do you mean MP->IP->EP ? >> >>> I do, but it's a mild one)... it just seems like something that hasn'= t >>> been thought out yet, and should be. >> Hm, I think we have already thought about it. >> According to the definition, an IPFIX Mediator includes at least one I= P >> and one EP (because it is an IPFIX Device). So, MP->IP->EP is an IPFIX= >> Mediator by definition. >> >=20 > I agreed. >=20 > Regards, > Atsushi >=20 >=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 --------------ms070509010307060002010202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjIyMTgwODU4WjAjBgkqhkiG9w0BCQQxFgQU 5Y/7nVJHSiRungrBAi5vz+nZ51gwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALw3KKyf5scpCHAapPpKpCHvOiZRwzCt2Wc5z36Gx3UQdbJk sCb72A206RGzhHebTTxfUz9fpoyCn+03CEr8tCkf4em/VrvyyDRpWdaTwzJp7yNmJZuzlePf +f6ZtyFToSoe/ebSghr5f3cQPQNEkr3YMyFGyP+L/iqzgzl7L6lD5cXOPe2JngnM1UTQI7DD 4C4Aok2ua33GsEdHX5H7Sace5yrUcL1sEERuJjn4lX3SXlkC3G9Wpg1oQhY53GO584TuLIAe hlsKa2HbeMvxB/YIlZjzMUJ6gi+q1j3rzt+ndGD+8ubmTes7bAW6Kps50Lnmt+vytP4IDO2c igL1vWMAAAAAAAA= --------------ms070509010307060002010202-- From akoba@orange.plala.or.jp Mon Jun 22 11:41:01 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1103A6898 for ; Mon, 22 Jun 2009 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 hF9D2jfzNMYY for ; Mon, 22 Jun 2009 11:41:00 -0700 (PDT) Received: from msa01b.plala.or.jp (msa01.plala.or.jp [58.93.240.1]) by core3.amsl.com (Postfix) with ESMTP id 9AB2D3A6801 for ; Mon, 22 Jun 2009 11:40:59 -0700 (PDT) Received: from [127.0.0.1] (really [118.21.13.32]) by msa01b.plala.or.jp with ESMTP id <20090622184113.KPPD18533.msa01b.plala.or.jp@[127.0.0.1]>; Tue, 23 Jun 2009 03:41:13 +0900 Date: Tue, 23 Jun 2009 03:41:15 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> References: <4A3BF0B4.20104@net.in.tum.de> <28575AEE-13CD-4730-94F0-E5EF041924BE@tik.ee.ethz.ch> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.068 Message-Id: <20090623033305.FC4E.AKOBA@orange.plala.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="Shift_JIS" Content-Transfer-Encoding: quoted-printable X-Mailer: Becky! ver. 2.25.02 [ja] X-VirusScan: Outbound; msa01b; Tue, 23 Jun 2009 03:41:13 +0900 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:41:01 -0000 Brian, Gerhard, Benoit and all, Let me know your opinion. On Mon, 22 Jun 2009 12:56:50 +0200 Brian Trammell wrote: > Gerhard, >=20 > Inline. >=20 > On Jun 19, 2009, at 10:10 PM, Gerhard Muenz wrote: >=20 > > > > Brian, > > > > I'm not sure if we need all this information in the terminology =20 > > section. > > Maybe, there is a better place them, either in another section of the > > draft or in the framework draft. >=20 > This is a different argument, which we seem to be converging in the =20 > direction of defining everything consistently twice, and allowing the =20 > problem statement to use the "real" terminology in its example. There =20 > are of course valid reasons not to do this, as well. I'm not sold =20 > either way, I'm just trying to follow consensus; if this is what we =20 > want in the terminology, then this is what it should look like. >=20 Thank you, Brian. Yes, I'm just trying to follow consensus. > I'm not at all certain that the Intermediate FOO Process definitions =20 > are necessary, but they do underscore that _devices_ we seem to have =20 > already defined are really just hosts for processes, and that =20 > processes are the important part. First of all, IMO, there is a better place that IPFIX XXXtor is introduced in problem statement, because first reader feels easily the image of implementation analysis. And the instances of Mediation functions are shown as Intermedeate Process in framework draft. Framework draft describes the components, or some functions in detail. Thus, I thought that IPFIX XXXtors are defined in Problem Statement,=20 IPFIX Intermedeate FOO Processes are defined in Framework.=20 But, regarding Brian's proposal that IPFIX XXXtor refers to Intermedeate FOO Process, I am not sure where is a better place for them yet. It is hard choice. We can choose three types. a) problem statement and framework describes whole terminologies, twice. In case of Brian's terminologies, we describes what is IPFIX Mediation, Mediator, and Intermediate Process in problem statement. It seems cover the framework description. =20 b) problem statement does not define terminologies, and then it elaborates about applicable examples without capital letter. c) problem statement defines some terms, framework defines some terms. I am not sure. One examples are that Problem statement defines IPFIX Mediation and Mediator. Framework defines others. What do you think about that? Regards, Atsushi >=20 > > BTW, there are several problems with your definitions. See inline. >=20 > Thanks for the comments; comments thereon below. :) >=20 > > Regards, > > Gerhard > > > > Brian Trammell wrote: > >> I propose the following unified terminology section, following the > >> thread to date: > >> > >> IPFIX Mediation describes the manipulation and conversion of records > >> exported using IPFIX, by applying mediation functions within one or = =20 > >> more > > > > "exported using IPFIX" should be removed, because they could have been > > exported using Netflow. >=20 > Negative, although I agree the phrasing is confusing here... What I =20 > meant was, the _output_ of mediation is necessarily and by definition =20 > IPFIX. In full, the correction should read as follows: >=20 > IPFIX Mediation describes the manipulation, conversion, and export of =20 > records via IPFIX, by applying mediation functions within one or more =20 > Intermediate Processes to a stream of records in an IPFIX Mediator. =20 > The following terms are used in this document to describe the =20 > architectural entities used by IPFIX Mediation. >=20 > >> Intemediate Process > >> > >> An Intermediate Process takes a sequence of records from a Collecting > >> Process, IPFIX File Reader, or another Intermediate Process within a > > > > The Metering Process is missing as a source of records. I wonder if we > > have to specify the sources at all. >=20 > Point. >=20 > >> Mediator; performs some transformation on these records based upon =20 > >> the > >> content of the records themselves, state kept across multiple =20 > >> records, > >> configuration parameters, or other data; and passes a sequence of > >> transformed records on to an Exporting Process, IPFIX File Writer, or > >> another Intermediate Process within a Mediator. This document =20 > >> describes > > > > Again, do we have to specify the sinks here? >=20 > I think so; I've tried constructing this definition without source/=20 > sink specifications and it sounds so general that it doesn't actually =20 > say anything at all. >=20 > >> specific Intermediate Processes below used in the elaboration of the > >> problem statement; however, this is not an exhaustive list. >=20 > Corrected: >=20 > Intermediate Process >=20 > An Intermediate Process takes a sequence of records from a Collecting > Process, Metering Process, IPFIX File Reader, or another Intermediate =20 > Process within a Mediator; performs some transformation on these =20 > records based upon the > content of the records themselves, state kept across multiple records, > configuration parameters, or other data; and passes a sequence of > transformed records on to an Exporting Process, IPFIX File Writer, or > another Intermediate Process within a Mediator. This document describes > specific Intermediate Processes below used in the elaboration of the > problem statement; however, this is not an exhaustive list. >=20 > >> Intermediate Aggregation Process > >> > >> An Intermediate Aggregation Process is an Intermediate Process that > >> aggregates records based upon a new set of Flow Key fields, or =20 > >> functions > >> applied to Flow Key fields (e.g. binning, subnet aggregation). > > > > It is also possible to aggregate PSAMP Packet Reports that do not have > > Flow Keys! So, we cannot assume that the original records have flow =20 > > key > > fields. >=20 > Point, however, aggregation by necessity requires some "keys" on which = =20 > to aggregate. So we can use lowercase "keys" (which I acknowledge =20 > risks confusing people... are keys Flow Keys?, but it's better than =20 > nothing.) >=20 > An Intermediate Aggregation Process is an Intermediate Process that > aggregates records based upon a set of key fields, or functions > applied to fields from the record (e.g. binning, subnet aggregation). >=20 > >> Intermediate Correlation Process > >> > >> An Intermediate Correlation Process is an Intermediate Process which > >> adds information to records noting correlations among them, or =20 > >> generates > >> new records with correlated data from multiple records (e.g. the > >> production of bidirectional flow records from unidirectional flow =20 > >> records). > >> > >> Intermediate Selection Process > >> > >> An Intermediate Selection Process is an Intermediate Process that > >> selects records from a sequence based upon criteria evaluated record > >> values, and passes only those records that match the criteria (e.g. > >> filtering only records from a given network to a given Collector). > >> > >> Intermediate Anonymisation Process > >> > >> An Intermediate Anonymisation Process is an Intermediate Process that > >> transforms records in order to anonymise them, to protect the =20 > >> identity > >> of the entities described by the records (e.g. by applying > >> prefix-preserving pseudonymisation of IP addresses). >=20 > (see above re: maybe we don't need these here.) >=20 > >> IPFIX Mediator > >> > >> An IPFIX Mediator is an IPFIX Device that provides mediation > >> capabilities by receiving records from some data source, hosting =20 > >> zero or > >> more Intermediate Processes to transform those records, and exporting > >> those records in IPFIX Messages via an Exporting Process. In the =20 > >> common > >> case, a Mediator receives records from a Collecting Process, but =20 > >> could > > > > What about records from a Metering Process? >=20 > Does a Mediator actually receive records directly from an MP, or is an = =20 > MP->IP->CP box something different? I don't have an opinion here =20 > (well, I do, but it's a mild one)... it just seems like something that = =20 > hasn't been thought out yet, and should be. >=20 > >> also receive records from data sources not encoded using IPFIX, =20 > >> e.g., in > >> the case of NetFlow V9 protocol translation. Specific types of =20 > >> Mediators > >> are defined below; some of these reference original mediation > >> capabilities defined in earlier IPFIX documens before the =20 > >> elaboration of > >> the Mediator problem statement. > >> > >> IPFIX Proxy > >> > >> An IPFIX Proxy is an IPFIX Mediator that relays incoming > >> IPFIX Messages or messages in other protocols to one or more =20 > >> Collectors. > >> It can provide transport protocol mediation and re-encoding. > >> > >> IPFIX Concentrator > >> > >> An IPFIX Concentrator is an IPFIX Mediator that recieves data from =20 > >> one > >> or more Exporters and sends them to a single Collector, optionally > >> transforming the records using zero or more Intermediate Processes on > >> the way. > >> > >> IPFIX Distributor > >> > >> An IPFIX Distributor is an IPFIX Mediator that recieves data from =20 > >> one or > >> more Exporters and sends them to one or more Collectors, deciding =20 > >> which > >> Collector(s) to send each record to based upon the decision of an > >> Intermediate Selection Process. > >> > >> IPFIX Masquerading Proxy > >> > >> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data = =20 > >> from > >> one or more Exporters and sends them to a single Collector, using =20 > >> one or > >> more Intermediate Aggregation Functions and Intermediate =20 > >> Anonymisation > >> Functions to screen out parts of records according to configured > >> policies, in order to protect the privacy of the network's end =20 > >> users or > >> senstive data of the exporting organization. > >> > >> > >> Best regards, > >> > >> Brian > >> _______________________________________________ > >> 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 > > > > >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From akoba@nttv6.net Mon Jun 22 17:54:52 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC56C3A6B20 for ; Mon, 22 Jun 2009 17:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 Conh6AxU9pQ3 for ; Mon, 22 Jun 2009 17:54:51 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 1920B3A687C for ; Mon, 22 Jun 2009 17:54:49 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:8019:ce64:a186:8e9]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5N0sxaN004210; Tue, 23 Jun 2009 09:54:59 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Tue, 23 Jun 2009 09:51:29 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A3FC8BA.4010708@net.in.tum.de> References: <20090623012914.FC4B.AKOBA@orange.plala.or.jp> <4A3FC8BA.4010708@net.in.tum.de> Message-Id: <20090623091703.38CC.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Tue, 23 Jun 2009 09:55:03 +0900 (JST) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 00:54:52 -0000 Hi Gerhard, Benoit, Falko, Emile, Christoph, and Nishida-san, On Mon, 22 Jun 2009 20:08:58 +0200 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > >> Brian Trammell wrote: > >>>> I'm not sure if we need all this information in the terminology section. > >>>> Maybe, there is a better place them, either in another section of the > >>>> draft or in the framework draft. > >>> This is a different argument, which we seem to be converging in the > >>> direction of defining everything consistently twice, and allowing the > >>> problem statement to use the "real" terminology in its example. There > >>> are of course valid reasons not to do this, as well. I'm not sold either > >>> way, I'm just trying to follow consensus; if this is what we want in the > >>> terminology, then this is what it should look like. > >>> > >>> I'm not at all certain that the Intermediate FOO Process definitions are > >>> necessary, but they do underscore that _devices_ we seem to have already > >>> defined are really just hosts for processes, and that processes are the > >>> important part. > >>> > >>>> BTW, there are several problems with your definitions. See inline. > >>> Thanks for the comments; comments thereon below. :) > >>> > >>>> Regards, > >>>> Gerhard > >>>> > >>>> Brian Trammell wrote: > >>>>> I propose the following unified terminology section, following the > >>>>> thread to date: > >>>>> > >>>>> IPFIX Mediation describes the manipulation and conversion of records > >>>>> exported using IPFIX, by applying mediation functions within one or more > >>>> "exported using IPFIX" should be removed, because they could have been > >>>> exported using Netflow. > >>> Negative, although I agree the phrasing is confusing here... > >> Indeed. I (mis)understood the phrase in a way that other people could to > >> as well ;) > >> > > Me, too. :) > > > >>> What I > >>> meant was, the _output_ of mediation is necessarily and by definition > >> Agreed. > >> > >>> IPFIX. In full, the correction should read as follows: > >>> > >>> IPFIX Mediation describes the manipulation, conversion, and export of > >>> records via IPFIX, by applying mediation functions within one or more > >>> Intermediate Processes to a stream of records in an IPFIX Mediator. The > >>> following terms are used in this document to describe the architectural > >>> entities used by IPFIX Mediation. > > > > Brian, let me know your definition in detail. > > Your definition looks like IPFIX Mediation is only implemented in IPFIX > > Mediator. IPFIX Mediation, that is Intermediate Processes, can be hosted > > in any device. > > > > And IPFIX Mediation definition refers to IPFIX Mediator, and IPFIX > > Mediator definition refers to mediation function. It seems a little bit > > strange for me. > > > > Or can you remove "in an IPFIX Mediator"? > > > >> I do not think that IPFIX Mediation "describes" the export of records. > >> I would change your original text in something like: > >> > >> "IPFIX Mediation describes the manipulation and conversion of records > >> for subsequent export using IPFIX, by applying mediation functions ..." > >> > > > > Gerhard, the above definition say that finally IPFIX exporting after > > executing IPFIX Mediation is implemented. Is it right? If Intermediate > > Process is hosted in NMS or Collector, this device would not export > > IPFIX. > > I'm not sure if we should consider IPFIX Mediation hosted in NMS aka > Collectors that do not reexport the data afterwards. > > Of course, NMS/Collectors typically analyze the received data, and the > analysis functions can be the same as in an IP. However, we do not need > to standardize what happens here because the data is not exported any more. > > I do not think that we should standardize how IPFIX data is treated > beyond the Collector. > I wonder we try to standardize IPFIX aggregation and anonymization. These functions can be applied to NMS/Collector as well as IPFIX Mediators. Maybe, one example of IPFIX aggregation and anonymization would be Mediator. It seems same thing for me. Even if the standardization of IPFIX Mediation covers only IPFIX Mediator, the IPFIX Mediation function can be applied to any devices, thus it should not restrict in its terminologies. I and co-authors decided the IPFIX Mediator terminologies as follows. IPFIX Mediator An IPFIX Mediator is an IPFIX Device that implements one or more IPFIX Mediation capabilities. Examples are devices such as routers, switches, network management systems (NMS), etc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ But, I don't have strong opinion about it. I will follow the consensus including co-authors. > > My original definition is as follows. > > > > IPFIX Mediation > > > > IPFIX Mediation is a generic function that covers the manipulation > > of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX > > Messages, or their transmission. The IPFIX Mediation offers one > > or multiple of the following capabilities: > > > > I would like to edit as follows. > > > > "IPFIX Mediation describes the manipulation and conversion of records or IPFIX > > Message, by applying..." > > If this is consensus, I would not oppose it. > > However, if you look at this: > > IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages--> > > then, the IP does not see/treat any IPFIX messages, just records. > In simple case, transport protocol is changed from UDP to SCTP. It is one-to-one transmission of incoming/outgoing IPFIX session. In that case, IP does not need to manipulate the records. > >>>>> Intemediate Process > >>>>> > >>>>> An Intermediate Process takes a sequence of records from a Collecting > >>>>> Process, IPFIX File Reader, or another Intermediate Process within a > >>>> The Metering Process is missing as a source of records. I wonder if we > >>>> have to specify the sources at all. > >>> Point. > >>> > >>>>> Mediator; performs some transformation on these records based upon the > >>>>> content of the records themselves, state kept across multiple records, > >>>>> configuration parameters, or other data; and passes a sequence of > >>>>> transformed records on to an Exporting Process, IPFIX File Writer, or > >>>>> another Intermediate Process within a Mediator. This document describes > >>>> Again, do we have to specify the sinks here? > >>> I think so; I've tried constructing this definition without source/sink > >>> specifications and it sounds so general that it doesn't actually say > >>> anything at all. > >>> > >>>>> specific Intermediate Processes below used in the elaboration of the > >>>>> problem statement; however, this is not an exhaustive list. > >>> Corrected: > >>> > >>> Intermediate Process > >>> > >>> An Intermediate Process takes a sequence of records from a Collecting > >>> Process, Metering Process, IPFIX File Reader, or another Intermediate > >>> Process within a Mediator; performs some transformation on these records > >>> based upon the > >>> content of the records themselves, state kept across multiple records, > >>> configuration parameters, or other data; and passes a sequence of > > > > Configuration parameter is good idea. > > > >>> transformed records on to an Exporting Process, IPFIX File Writer, or > >>> another Intermediate Process within a Mediator. This document describes > >>> specific Intermediate Processes below used in the elaboration of the > >>> problem statement; however, this is not an exhaustive list. > >> Nice. > >> > >>>>> Intermediate Aggregation Process > >>>>> > >>>>> An Intermediate Aggregation Process is an Intermediate Process that > >>>>> aggregates records based upon a new set of Flow Key fields, or functions > >>>>> applied to Flow Key fields (e.g. binning, subnet aggregation). > >>>> It is also possible to aggregate PSAMP Packet Reports that do not have > >>>> Flow Keys! So, we cannot assume that the original records have flow key > >>>> fields. > >>> Point, however, aggregation by necessity requires some "keys" on which > >>> to aggregate. So we can use lowercase "keys" (which I acknowledge risks > >>> confusing people... are keys Flow Keys?, but it's better than nothing.) > >>> > >>> An Intermediate Aggregation Process is an Intermediate Process that > >>> aggregates records based upon a set of key fields, or functions > >>> applied to fields from the record (e.g. binning, subnet aggregation). > >> In the first paraphrase of the original text, there is no problem with > >> "Flow Keys" as they may come from the configuration of the IP: > >> > >> An Intermediate Aggregation Process is an Intermediate Process that > >> aggregates records based upon a set of Flow Keys, or functions > >> applied to fields from the record (e.g. binning, subnet aggregation). > >> > > > > Um.., problem statement and framework proposes "spatial composition". In > > that case, Exporter IP address, or Observation Domain ID, or some > > identifier based on observation information becomes key fields, thus, > > original Flow Records does not includes Flow Key fields. I am not sure > > the definition can cover the spatial composition. > > I do not understand where the problem should be. > > In my opinion, the output of the aggregation process is a stream of Flow > Records. These Flow Records have Flow Keys. These Flow Keys do not have > to be the same as those potentially included in the records that entered > the aggregation process. > > My definition does not mention, where the Flow Keys come from. I would > suggest that they typically come from configuration. > OK. I understand. Regards, Atsushi > Regards, > Gerhard > > >>>>> Intermediate Correlation Process > >>>>> > >>>>> An Intermediate Correlation Process is an Intermediate Process which > >>>>> adds information to records noting correlations among them, or generates > >>>>> new records with correlated data from multiple records (e.g. the > >>>>> production of bidirectional flow records from unidirectional flow > >>>>> records). > >>>>> > >>>>> Intermediate Selection Process > >>>>> > >>>>> An Intermediate Selection Process is an Intermediate Process that > >>>>> selects records from a sequence based upon criteria evaluated record > >>>>> values, and passes only those records that match the criteria (e.g. > >>>>> filtering only records from a given network to a given Collector). > >>>>> > >>>>> Intermediate Anonymisation Process > >>>>> > >>>>> An Intermediate Anonymisation Process is an Intermediate Process that > >>>>> transforms records in order to anonymise them, to protect the identity > >>>>> of the entities described by the records (e.g. by applying > >>>>> prefix-preserving pseudonymisation of IP addresses). > >>> (see above re: maybe we don't need these here.) > >>> > >>>>> IPFIX Mediator > >>>>> > >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>>>> capabilities by receiving records from some data source, hosting zero or > >>>>> more Intermediate Processes to transform those records, and exporting > >>>>> those records in IPFIX Messages via an Exporting Process. In the common > >>>>> case, a Mediator receives records from a Collecting Process, but could > >>>> What about records from a Metering Process? > >>> Does a Mediator actually receive records directly from an MP, or is an > >>> MP->IP->CP box something different? I don't have an opinion here (well, > >> Do you mean MP->IP->EP ? > >> > >>> I do, but it's a mild one)... it just seems like something that hasn't > >>> been thought out yet, and should be. > >> Hm, I think we have already thought about it. > >> According to the definition, an IPFIX Mediator includes at least one IP > >> and one EP (because it is an IPFIX Device). So, MP->IP->EP is an IPFIX > >> Mediator by definition. > >> > > > > I agreed. > > > > Regards, > > Atsushi > > > > > > -- > 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 NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From dressler@informatik.uni-erlangen.de Mon Jun 22 23:23:06 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C088328C27D for ; Mon, 22 Jun 2009 23:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4hDwgVDYoXB for ; Mon, 22 Jun 2009 23:23:05 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id 645353A6DE2 for ; Mon, 22 Jun 2009 23:23:04 -0700 (PDT) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4067F4B9F; Tue, 23 Jun 2009 08:23:19 +0200 (MEST) Received: from [131.188.37.59] (faui7n2.informatik.uni-erlangen.de [131.188.37.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id 11C3B438183; Tue, 23 Jun 2009 08:23:19 +0200 (CEST) Message-ID: <4A4074D2.5020205@informatik.uni-erlangen.de> Date: Tue, 23 Jun 2009 08:23:14 +0200 From: Falko Dressler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090623012914.FC4B.AKOBA@orange.plala.or.jp> <4A3FC8BA.4010708@net.in.tum.de> <20090623091703.38CC.17391CF2@nttv6.net> In-Reply-To: <20090623091703.38CC.17391CF2@nttv6.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 06:23:06 -0000 Kobayashi-san, all, On 23.06.2009 02:51, Atsushi Kobayashi wrote: ... >>>>> IPFIX Mediation describes the manipulation, conversion, and export of >>>>> records via IPFIX, by applying mediation functions within one or more >>>>> Intermediate Processes to a stream of records in an IPFIX Mediator. The >>>>> following terms are used in this document to describe the architectural >>>>> entities used by IPFIX Mediation. >>> Brian, let me know your definition in detail. >>> Your definition looks like IPFIX Mediation is only implemented in IPFIX >>> Mediator. IPFIX Mediation, that is Intermediate Processes, can be hosted >>> in any device. ... >>>> I do not think that IPFIX Mediation "describes" the export of records. >>>> I would change your original text in something like: >>>> >>>> "IPFIX Mediation describes the manipulation and conversion of records >>>> for subsequent export using IPFIX, by applying mediation functions ..." >>>> >>> Gerhard, the above definition say that finally IPFIX exporting after >>> executing IPFIX Mediation is implemented. Is it right? If Intermediate >>> Process is hosted in NMS or Collector, this device would not export >>> IPFIX. >> I'm not sure if we should consider IPFIX Mediation hosted in NMS aka >> Collectors that do not reexport the data afterwards. >> >> Of course, NMS/Collectors typically analyze the received data, and the >> analysis functions can be the same as in an IP. However, we do not need >> to standardize what happens here because the data is not exported any more. >> >> I do not think that we should standardize how IPFIX data is treated >> beyond the Collector. >> > > I wonder we try to standardize IPFIX aggregation and anonymization. These > functions can be applied to NMS/Collector as well as IPFIX Mediators. > Maybe, one example of IPFIX aggregation and anonymization would be Mediator. > It seems same thing for me. > > Even if the standardization of IPFIX Mediation covers only IPFIX > Mediator, the IPFIX Mediation function can be applied to any devices, > thus it should not restrict in its terminologies. > > I and co-authors decided the IPFIX Mediator terminologies as follows. > > IPFIX Mediator > > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > But, I don't have strong opinion about it. I will follow the consensus > including co-authors. Well, back to the original meaning of IPFIX Mediation, I still prefer the "manipulation" of data (or more precisely, received IPFIX records). Thus, functionality on the receiving NMS system might be described by means of IPFIX mediation, but, of course, there is no need to follow standardized rules here. As for the suggested definition of an IPFIX Mediator, I would recommend to drop the sentence "Examples are ... NMS..." This might be misleading. Best regards, Falko -- Dr. Falko Dressler Computer Networks and Communication Systems University of Erlangen, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 mailto:dressler@informatik.uni-erlangen.de http://www7.informatik.uni-erlangen.de/~dressler/ From muenz@net.in.tum.de Tue Jun 23 04:05:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC4A728C0E5 for ; Tue, 23 Jun 2009 04:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=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 gjuedod+BQCR for ; Tue, 23 Jun 2009 04:05:40 -0700 (PDT) Received: from mail-out2.informatik.tu-muenchen.de (mail-out2.informatik.tu-muenchen.de [131.159.0.36]) by core3.amsl.com (Postfix) with ESMTP id 0114B3A6BA6 for ; Tue, 23 Jun 2009 04:05:39 -0700 (PDT) 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 75F94483DE; Tue, 23 Jun 2009 13:05:52 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 61A4F5043; Tue, 23 Jun 2009 13:05:52 +0200 (CEST) Message-ID: <4A40B76A.2010805@net.in.tum.de> Date: Tue, 23 Jun 2009 13:07:22 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090623012914.FC4B.AKOBA@orange.plala.or.jp> <4A3FC8BA.4010708@net.in.tum.de> <20090623091703.38CC.17391CF2@nttv6.net> In-Reply-To: <20090623091703.38CC.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080805090506000502010901" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 11:05:41 -0000 This is a cryptographically signed message in MIME format. --------------ms080805090506000502010901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Atsushi, Atsushi Kobayashi wrote: >>>> "IPFIX Mediation describes the manipulation and conversion of record= s >>>> for subsequent export using IPFIX, by applying mediation functions .= =2E." >>>> >>> Gerhard, the above definition say that finally IPFIX exporting after >>> executing IPFIX Mediation is implemented. Is it right? If Intermediat= e >>> Process is hosted in NMS or Collector, this device would not export >>> IPFIX. >> I'm not sure if we should consider IPFIX Mediation hosted in NMS aka >> Collectors that do not reexport the data afterwards. >> >> Of course, NMS/Collectors typically analyze the received data, and the= >> analysis functions can be the same as in an IP. However, we do not nee= d >> to standardize what happens here because the data is not exported any = more. >> >> I do not think that we should standardize how IPFIX data is treated >> beyond the Collector. >=20 > I wonder we try to standardize IPFIX aggregation and anonymization. The= se > functions can be applied to NMS/Collector as well as IPFIX Mediators. > Maybe, one example of IPFIX aggregation and anonymization would be Medi= ator.=20 > It seems same thing for me. >=20 > Even if the standardization of IPFIX Mediation covers only IPFIX > Mediator, the IPFIX Mediation function can be applied to any devices, > thus it should not restrict in its terminologies. >=20 > I and co-authors decided the IPFIX Mediator terminologies as follows. >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that implements one or more > IPFIX Mediation capabilities. Examples are devices such as > routers, switches, network management systems (NMS), etc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > But, I don't have strong opinion about it. I will follow the consensus > including co-authors. RFC5101 defines an IPFIX Device "an IPFIX Device hosts at least one Exporting Process." If you define an IPFIX Mediator is an IPFIX Device, there always is an Exporting Process in the same device. If you understand NMS as a Collector which does not reexport the data, then this is not an IPFIX Mediator by definition. >>> My original definition is as follows. >>> >>> IPFIX Mediation >>> >>> IPFIX Mediation is a generic function that covers the manipulat= ion >>> of IPFIX Flow Records, PSAMP Packet Reports, or entire IPFIX >>> Messages, or their transmission. The IPFIX Mediation offers on= e >>> or multiple of the following capabilities: >>> >>> I would like to edit as follows. >>> >>> "IPFIX Mediation describes the manipulation and conversion of records= or IPFIX >>> Message, by applying..." >> If this is consensus, I would not oppose it. >> >> However, if you look at this: >> >> IPFIX messages--> CP --records--> IP --records--> EP --IPFIX messages-= -> >> >> then, the IP does not see/treat any IPFIX messages, just records. >> >=20 > In simple case, transport protocol is changed from UDP to SCTP. It is > one-to-one transmission of incoming/outgoing IPFIX session. > In that case, IP does not need to manipulate the records. In my opinion, a change of the transport protocol below IPFIX does not require any IP: CP --> EP This setup is shown in RFC3917, Figure 2. Gerhard >>>>>>> Intemediate Process >>>>>>> >>>>>>> An Intermediate Process takes a sequence of records from a Collec= ting >>>>>>> Process, IPFIX File Reader, or another Intermediate Process withi= n a >>>>>> The Metering Process is missing as a source of records. I wonder i= f we >>>>>> have to specify the sources at all. >>>>> Point. >>>>> >>>>>>> Mediator; performs some transformation on these records based upo= n the >>>>>>> content of the records themselves, state kept across multiple rec= ords, >>>>>>> configuration parameters, or other data; and passes a sequence of= >>>>>>> transformed records on to an Exporting Process, IPFIX File Writer= , or >>>>>>> another Intermediate Process within a Mediator. This document des= cribes >>>>>> Again, do we have to specify the sinks here? >>>>> I think so; I've tried constructing this definition without source/= sink >>>>> specifications and it sounds so general that it doesn't actually sa= y >>>>> anything at all. >>>>> >>>>>>> specific Intermediate Processes below used in the elaboration of = the >>>>>>> problem statement; however, this is not an exhaustive list. >>>>> Corrected: >>>>> >>>>> Intermediate Process >>>>> >>>>> An Intermediate Process takes a sequence of records from a Collecti= ng >>>>> Process, Metering Process, IPFIX File Reader, or another Intermedia= te >>>>> Process within a Mediator; performs some transformation on these re= cords >>>>> based upon the >>>>> content of the records themselves, state kept across multiple recor= ds, >>>>> configuration parameters, or other data; and passes a sequence of >>> Configuration parameter is good idea. >>> >>>>> transformed records on to an Exporting Process, IPFIX File Writer, = or >>>>> another Intermediate Process within a Mediator. This document descr= ibes >>>>> specific Intermediate Processes below used in the elaboration of th= e >>>>> problem statement; however, this is not an exhaustive list. >>>> Nice. >>>> >>>>>>> Intermediate Aggregation Process >>>>>>> >>>>>>> An Intermediate Aggregation Process is an Intermediate Process th= at >>>>>>> aggregates records based upon a new set of Flow Key fields, or fu= nctions >>>>>>> applied to Flow Key fields (e.g. binning, subnet aggregation). >>>>>> It is also possible to aggregate PSAMP Packet Reports that do not = have >>>>>> Flow Keys! So, we cannot assume that the original records have flo= w key >>>>>> fields. >>>>> Point, however, aggregation by necessity requires some "keys" on wh= ich >>>>> to aggregate. So we can use lowercase "keys" (which I acknowledge r= isks >>>>> confusing people... are keys Flow Keys?, but it's better than nothi= ng.) >>>>> >>>>> An Intermediate Aggregation Process is an Intermediate Process that= >>>>> aggregates records based upon a set of key fields, or functions >>>>> applied to fields from the record (e.g. binning, subnet aggregation= ). >>>> In the first paraphrase of the original text, there is no problem wi= th >>>> "Flow Keys" as they may come from the configuration of the IP: >>>> >>>> An Intermediate Aggregation Process is an Intermediate Process that >>>> aggregates records based upon a set of Flow Keys, or functions >>>> applied to fields from the record (e.g. binning, subnet aggregation)= =2E >>>> >>> Um.., problem statement and framework proposes "spatial composition".= In >>> that case, Exporter IP address, or Observation Domain ID, or some >>> identifier based on observation information becomes key fields, thus,= >>> original Flow Records does not includes Flow Key fields. I am not sur= e >>> the definition can cover the spatial composition. >> I do not understand where the problem should be. >> >> In my opinion, the output of the aggregation process is a stream of Fl= ow >> Records. These Flow Records have Flow Keys. These Flow Keys do not hav= e >> to be the same as those potentially included in the records that enter= ed >> the aggregation process. >> >> My definition does not mention, where the Flow Keys come from. I would= >> suggest that they typically come from configuration. >> >=20 > OK. I understand. >=20 > Regards, > Atsushi >=20 >> Regards, >> Gerhard >> >>>>>>> Intermediate Correlation Process >>>>>>> >>>>>>> An Intermediate Correlation Process is an Intermediate Process wh= ich >>>>>>> adds information to records noting correlations among them, or ge= nerates >>>>>>> new records with correlated data from multiple records (e.g. the >>>>>>> production of bidirectional flow records from unidirectional flow= >>>>>>> records). >>>>>>> >>>>>>> Intermediate Selection Process >>>>>>> >>>>>>> An Intermediate Selection Process is an Intermediate Process that= >>>>>>> selects records from a sequence based upon criteria evaluated rec= ord >>>>>>> values, and passes only those records that match the criteria (e.= g. >>>>>>> filtering only records from a given network to a given Collector)= =2E >>>>>>> >>>>>>> Intermediate Anonymisation Process >>>>>>> >>>>>>> An Intermediate Anonymisation Process is an Intermediate Process = that >>>>>>> transforms records in order to anonymise them, to protect the ide= ntity >>>>>>> of the entities described by the records (e.g. by applying >>>>>>> prefix-preserving pseudonymisation of IP addresses). >>>>> (see above re: maybe we don't need these here.) >>>>> >>>>>>> IPFIX Mediator >>>>>>> >>>>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>>>> capabilities by receiving records from some data source, hosting = zero or >>>>>>> more Intermediate Processes to transform those records, and expor= ting >>>>>>> those records in IPFIX Messages via an Exporting Process. In the = common >>>>>>> case, a Mediator receives records from a Collecting Process, but = could >>>>>> What about records from a Metering Process? >>>>> Does a Mediator actually receive records directly from an MP, or is= an >>>>> MP->IP->CP box something different? I don't have an opinion here (w= ell, >>>> Do you mean MP->IP->EP ? >>>> >>>>> I do, but it's a mild one)... it just seems like something that has= n't >>>>> been thought out yet, and should be. >>>> Hm, I think we have already thought about it. >>>> According to the definition, an IPFIX Mediator includes at least one= IP >>>> and one EP (because it is an IPFIX Device). So, MP->IP->EP is an IPF= IX >>>> Mediator by definition. >>>> >>> I agreed. >>> >>> Regards, >>> Atsushi >>> >>> >> --=20 >> Dipl.-Ing. Gerhard M?z >> Chair for Network Architectures and Services (I8) >> Department of Informatics >> Technische Universit? M?chen >> Boltzmannstr. 3, 85748 Garching bei M?chen, 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 > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=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 --------------ms080805090506000502010901 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjIzMTEwNzIyWjAjBgkqhkiG9w0BCQQxFgQU A96Y/Ann0nehsmkztXwYgWhVPVwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGy2FMRXE4DvfDwixsy5x+uqUCqkfQr+9x94sq2Jt85lEoKp JoFblFInTceJBVPTp4uXBsiuLB/Axs8LCddljW/lkBfQRq9jQWK1SK1nO/pYZKXZVxhQNCTp IHskVbItNyKvkwzf+q9qjfLl+MejUGsX0dg7pgKrS2Wkhc7LaLYH/Je8KQPjTrauNzy6tMHA BHRWeFsJvqIFJYUk60CMUChZSS+BxEa9xsp+QbE3b2+cPRsgsnPjE7Ae+UedVpehovcoJQdi FYGc6GvuF10b28qJdCnvnIf6sGWr5e/Mbj1js5UabatmFgdQ/d5AxLgCHaIhSAMhExjEkbeX LuyQqeQAAAAAAAA= --------------ms080805090506000502010901-- From Saverio.Niccolini@nw.neclab.eu Wed Jun 24 00:46:47 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21553A6F58 for ; Wed, 24 Jun 2009 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8HzhIQqypwI for ; Wed, 24 Jun 2009 00:46:47 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D85243A6F4A for ; Wed, 24 Jun 2009 00:46:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id AAB8D2C00C51C for ; Wed, 24 Jun 2009 09:46:15 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C73cbUfjdXNH for ; Wed, 24 Jun 2009 09:46:15 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 8E86F2C0004E5 for ; Wed, 24 Jun 2009 09:46:10 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 09:46:06 +0200 Message-ID: <547F018265F92642B577B986577D671C9E3B8E@VENUS.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SIP/RTP extensions to IPFIX: SIPFIX Thread-Index: Acn0n9S1eGO55VB+RmGwc6wJzPiUsQ== From: "Saverio Niccolini" To: Subject: [IPFIX] SIP/RTP extensions to IPFIX: SIPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 07:46:47 -0000 Dear all, we just submitted the draft about SIP/RTP extensions to IPFIX: http://www.ietf.org/internet-drafts/draft-huici-ipfix-sipfix-00.txt The current draft (to make it easier to read) presents the problem-statement and the standardizing solution all in one document. If this draft proceeds we will take care of splitting these two items later on. The first question for the group is: is this something you would like to discuss in the context of this WG? We know from our experience that currently information about=20 SIP and RTP sessions is exported in proprietary ways and that=20 would be useful to have L7 information in the IPFIX to enable=20 better (and application-aware) monitoring solutions at collectors (or mediators). Let us know any comments you can have, Saverio =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-118 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 saverio.niccolini@nw.neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 =A0=20 From muenz@net.in.tum.de Thu Jun 25 12:20:00 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7533A69B3 for ; Thu, 25 Jun 2009 12:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=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 Uc43NGZCbze6 for ; Thu, 25 Jun 2009 12:19:58 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id BFCFE3A6A5B for ; Thu, 25 Jun 2009 12:19:34 -0700 (PDT) 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 73214489E2 for ; Thu, 25 Jun 2009 21:18:13 +0200 (CEST) Received: from [131.159.20.108] (repulse.net.informatik.tu-muenchen.de [131.159.20.108]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 6219750D9; Thu, 25 Jun 2009 21:18:13 +0200 (CEST) Message-ID: <4A43CDD2.3050104@net.in.tum.de> Date: Thu, 25 Jun 2009 21:19:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "ipfix@ietf.org Working Group" References: <49B10249.9040500@cisco.com> <49B11ED6.9070706@net.in.tum.de> <49B13015.6070001@net.in.tum.de> <1E797ED7-797A-4169-822B-45E674A912D1@tik.ee.ethz.ch> <49B13C75.70004@net.in.tum.de> <2A9198A6-8FF0-471D-A8F0-D605A3CEE707@tik.ee.ethz.ch> <4A1EEBB0.3040201@net.in.tum.de> In-Reply-To: <4A1EEBB0.3040201@net.in.tum.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070209090205080204080600" X-Virus-Scanned: ClamAV using ClamSMTP Cc: Daniel Mentz Subject: Re: [IPFIX] IPFIX configuration: (D)TLS authentication X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 19:20:00 -0000 This is a cryptographically signed message in MIME format. --------------ms070209090205080204080600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, Coming back to the configuration of mutual authentication between Exporting Processes and Collectiong Processes, please find below the text that I plan to add to the draft. Please comment. We could add further parameters to the TransportLayerSecurity class if necessary, e.g. to specify if message authentication or encryption is to be used, the crypto-algorithm etc. I'm not sure, if the WG wants to go that far. Regards, Gerhard 5.4.1. Destination Class +-------------------------------------+ | Destination | +-------------------------------------+ 0..1 +-----------------+ | [name] |<>------| TransportLayer- | | exportMemberType | | Security | | ipfixVersion | +-----------------+ | transportProtocol | | destinationIpAddress | | destinationPort | | sourceIpAddress (UDP) | | localIpAddress* (SCTP) | | sendBufferSize | | rateLimit | | timedReliability (SCTP) | | numberOfStreams (SCTP) | | orderedDelivery (SCTP) | | templateRefreshTimeout (UDP) | | optionsTemplateRefreshTimeout (UDP) | | templateRefreshPacket (UDP) | | optionsTemplateRefreshPacket (UDP) | +-------------------------------------+ Figure 13: Destination class [...] Using the TransportLayerSecurity class, transport layer security is enabled and configured for this export destination. If the transport protocol is SCTP or UDP, transport layer security is realized using DTLS. In the case of TCP, TLS is used instead. [...] 5.5.1. Receiver Class +--------------------------+ | Receiver | +--------------------------+ 0..1 +------------------------+ | [name] |<>------| TransportLayerSecurity | | transportProtocol | +------------------------+ | localIpAddress* | | localPort | | maxAllowedStreams (SCTP) | | templateLifetime (UDP) | +--------------------------+ Figure 18: Receiver class [...] Using the TransportLayerSecurity class, transport layer security using DTLS and TLS is enabled and configured for this listening socket of the Collecting Process. If the transport protocol is SCTP or UDP, transport layer security is realized using DTLS. In the case of TCP, TLS is used instead. [...] 5.6. Transport Layer Security Class +---------------------------------+ | TransportLayerSecurity | +---------------------------------+ | offeredCertificateAuthorityDN* | | offeredSubjectDN* | | offeredSubjectFQDN* | | acceptedCertificateAuthorityDN* | | acceptedSubjectDN* | | acceptedSubjectFQDN* | +---------------------------------+ Figure 20: TransportLayerSecurity class The TransportLayerSecurity class can be used in the Exporting Process's Destination class and the Collecting Process's Receiver class to enable and configure transport layer security for IPFIX. Depending on the transport protocol, DTLS or TLS are used as specified in [RFC5101]. The mutual authentication of Exporting Processes and Collecting Process can be controlled by the following parameters: offeredCertificateAuthorityDN: This parameter restricts authentication of the local endpoint during the TLS/DTLS handshake to X.509 certificates issued by the given certificate authority. The parameter contains the distinghished name of the certificate authority. The parameter MAY appear multiple times to specify a list of certificate authorities whose certificates can be used by the local endpoint. Certificates issued by any certificate authority that is not contained in the list MUST NOT be sent to the remote peer during TLS/DTLS handshake. If offeredCertificateAuthorityDN is not configured, the local endpoint may use certificates of any certificate authority for authentication. offeredSubjectDN, offeredSubjectFQDN: These parameters restrict authentication of the local endpoint during the TLS/DTLS handshake to X.509 certificates issued for a specific subject. offeredSubjectDN contains a distinghished name which identifies the local endpoint; this distinghished name is included in the subject of the X.509 certificate. offeredSubjectFQDN contains a fully-qualified domain name which is assigned to the local endpoint; this fully-qualified domain name is included in the dNSName of the subject alternative extension field or in the commonName of the subject field of the X.509 certificate as specified in [RFC5101]. Both parameters MAY appear multiple times to specify a list of subjects and fully-quailfied domain names the local endpoint is allowed to use to authenticate itself. X.509 certificates sent to the remote peer during TLS/DTLS handshake MUST contain one of the specified distinghished names in the subject field or at least one of the specified fully-qualified domain names in the dNSName of the subject alternative extension field or in the common name of the subject field. The Monitoring Device MUST ensure that the X.509 certificate actually identifies the local endpoint before sending it to the remote peer. If any of the parameters offeredSubjectDN and offeredSubjectFQDN is configured at the same time as the offeredCertificateAuthorityDN parameter, certificates MUST also fulfill the specified restrictions regarding the certificate authority. If offeredSubjectDN and offeredSubjectFQDN are not configured, the local endpoint may use certificates with any distinguished name or fully-qualified domain name. acceptedCertificateAuthorityDN: This parameter restricts authentication of the remote peer during the TLS/DTLS handshake to X.509 certificates issued by the given certificate authority. The parameter contains the distinghished name of the certificate authority. The parameter MAY appear multiple times to specify a list of certificate authorities whose certificates are accepted. Certificates issued by any certificate authority that is not contained in the list MUST be rejected during TLS/DTLS handshake. If acceptedCertificateAuthorityDN is not configured, certificates of any certificate authority are accepted. acceptedSubjectDN, acceptedSubjectFQDN: These parameters restrict authentication of remote peers during the TLS/DTLS handshake to X.509 certificates issued for a specific subject. acceptedSubjectDN contains a distinghished name that is accepted in the subject field of the X.509 certificate. acceptedSubjectFQDN contains a fully-qualified domain name that is accepted in the dNSName of the subject alternative extension field or in the commonName of the subject field of the X.509 certificate as specified in [RFC5101]. Both parameters MAY appear multiple times to specify a list of accepted subjects and fully-quailfied domain names. A X.509 certificate received during TLS/DTLS handshake from the remote peer MUST only be accepted if it contains one of the specified distinghished names in the subject field or at least one of the specified fully-qualified domain names in the dNSName of the subject alternative extension field or in the common name of the subject field. If any of the parameters acceptedSubjectDN and acceptedSubjectFQDN is configured at the same time as the acceptedCertificateAuthorityDN parameter, certificates MUST also fulfill the specified restrictions regarding the certificate authority in order to be accepted. If acceptedSubjectDN and acceptedSubjectFQDN are not configured, any distinguished name and any fully-qualified domain name belonging to the remote peer are accepted. Note that transport layer security can be enabled without configuring any of the parameters. In this case, an empty XML element appears in the configuration. Gerhard Muenz wrote: > Hi all, >=20 > Regarding the configuration of (D)TLS, one of my students pointed out > that RFC 5101 specifies to authenticate Exporting and Collecting > Processes by FQDNs: >=20 > 11.3. Authentication >=20 > IPFIX Exporting Processes and IPFIX Collecting Processes are > identified by the fully qualified domain name of the interface on > which IPFIX Messages are sent or received, for purposes of X.509 > client and server certificates as in [RFC3280]. >=20 > The FQDN can be stored in a subjectAltName extension or the Common Name= > field of the X.509 certificate. subjectAltName seems to be the preferre= d > solution. >=20 > RFC 5101 says: >=20 > Each of the IPFIX Exporting and > Collecting Processes MUST verify the identity of its peer against it= s > authorized certificates, and MUST verify that the peer's certificate= > matches its fully qualified domain name, or, in the case of SCTP, th= e > fully qualified domain name of one of its endpoints. >=20 > I assume that the configuration data model should enable the > configuration of which certificates are "authorized". > In general, I see three cases: >=20 > 1) any valid certificate is authorized > 2) only a valid certificate issued by one out of a given list of CAs is= > authorized > 3) only a valid certificate for one out of a given list of FQDNs issued= > by one out of a given list of CAs is accepted >=20 > So, I would add the following parameters at appropriate places to the > Exporting Process and Collecting Process parameter sets: >=20 > - certificateAuthority: Common Name of the accepted CA > - [collectingProcess|exportingProcess]DomainName: FQDN of accepted CP|E= P > (without specifying if the FQDN is expected to appear in the CN field= > of the Subject or in the subjectAltName extension) >=20 > I hope that the Common Name is enough to identify the CA unambiguously.= >=20 > How about endpoints that have multiple certificates available (e.g., > issued by different CAs)? In this case, it might be interesting to > configure which certificate(s) the endpoint should offer the other > endpoint for identification. >=20 > So, we would be able to specify both certificates _used_ and > certificates _accepted_ by an Exporting Process or Collection Process. >=20 > Opinions? >=20 > BTW, the second part of the above quote from RFC5101 ("MUST verify that= > the peer's certificate matches its fully qualified domain name") seems > to require a DNS lookup, or how is it supposed to work? >=20 > Regards, > Gerhard >=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 --------------ms070209090205080204080600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjI1MTkxOTQ2WjAjBgkqhkiG9w0BCQQxFgQU /yTU92qa7OOi5ILr8oUBQ87Ld/AwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAEpTXhW3b9H9OEiDKsGb5TmjRywKUjCn2dcOKa0uAWcCMOfx jKZC4/kE+e2r8lxZSXNCaIhyOWO0gjZFu2W/Mml7BRNd4cbP8CsCTYyLBEJORs7568ncP2sg LUFQ2KrpfKNLW13n/+mjwyp6du5Cm66qz71TEGiJ1L4ue1LLKxBqZoeWADA0V0JJcfn5Q8EV sjREiu8txmnOUyLI1QaBYhPfHBRQrWX49FCwPzPzSpRvr080tifGIw5AUrYxJ7d6lOkVnaB+ qb1UCMstu2vz/s9qjAQAE1Wkw01Syb4fw5DODX/IHs1nkeL/BCwhp4EUsz6MLB6C4U5tgk9V jqH1YRAAAAAAAAA= --------------ms070209090205080204080600-- From bclaise@cisco.com Fri Jun 26 05:44:28 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74DAC3A67DB; Fri, 26 Jun 2009 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=-0.192, 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 N+4QWODXiPGa; Fri, 26 Jun 2009 05:44:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 71C833A67B3; Fri, 26 Jun 2009 05:44:27 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5QChEEj024204; Fri, 26 Jun 2009 14:43:15 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5QChEkn001717; Fri, 26 Jun 2009 14:43:14 +0200 (CEST) Message-ID: <4A44C262.3070301@cisco.com> Date: Fri, 26 Jun 2009 14:43:14 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" , ops-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stan yates Subject: [IPFIX] draft-claise-structured-data-in-ipfix-01 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 12:44:28 -0000 Dear all, A new version of the IPFIX structured is in the process of being posted (manual post requested) Note: as requested by Dan in the OPS-AREA meeting minutes, I'll include OPS-AREA in the email Most of the points discussed during both the IPFIX and OPS-AREA meetings were addressed. - more justifications why we need this structured data type and why appropriate protocols are not suitable - less focus on security. More example related to IPFIX, such as list of interfaces in a multicast flow, such as the MPLS label stack entry, - discussion about the recursive structured data - connection with the current IPFIX mediation function work. - connection with the one-way delay export, specified in PSAMP - Example of an aggregated observation point in a mediation function, which might be needed as a scope in an options template record - etc... As always, your feedback is welcome Regards, Benoit. From bclaise@cisco.com Fri Jun 26 09:24:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D6953A67A6 for ; Fri, 26 Jun 2009 09:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=0.830, BAYES_00=-2.599, GB_I_LETTER=-2] 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 eJOOeMQTyoDZ for ; Fri, 26 Jun 2009 09:24:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0DB473A6A36 for ; Fri, 26 Jun 2009 09:24:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5QGP4C5011094 for ; Fri, 26 Jun 2009 18:25:04 +0200 (CEST) Received: from [10.55.43.53] (ams-bclaise-8714.cisco.com [10.55.43.53]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n5QGP4ps008504 for ; Fri, 26 Jun 2009 18:25:04 +0200 (CEST) Message-ID: <4A44F660.1090300@cisco.com> Date: Fri, 26 Jun 2009 18:25:04 +0200 From: Benoit Claise User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 16:24:49 -0000 Dear all, I'm trying to summarize the long email thread. Not easy, there are some diverging opinions. I hope I haven't forgotten anything Below is the terminology proposal, based on Brian's proposal, improved by Gerhard, and everybody. 2. Terminology and Definitions The terms in this section are in line with those in the IPFIX Protocol specifications [RFC5101] and the PSAMP specification document [RFC5476]. The terms Observation Point, Observation Domain, Flow Key, Flow Record, Data Record, Exporting Process, Exporter, IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering Process, Transport Session, Information Element, and Template Withdrawal Message, are defined in the IPFIX protocol specifications [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP Device, and Configured Selection Fraction are defined in the PSAMP specification document [RFC5476]. Furthermore, new terminology to be used in the context of IPFIX Mediation is defined in this section. All these terms have an initial capital letter in this document. In this document, we use the generic term "Data Records" for IPFIX Flow Records, PSAMP Packet Reports, Data Records defined by Options Templates, unless an explicit distinction is required. Original Exporter Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed. IPFIX Mediation IPFIX Mediation describes the manipulation and conversion of records for subsequent export using IPFIX, by applying mediation functions within one or more Intermediate Processes to a stream of records in an IPFIX Mediator. The following terms are used in this document to describe the architectural entities used by IPFIX Mediation. Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process within a Mediator; performs some transformation on these records based upon the content of the records themselves, state kept across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process within a Mediator. This document describes specific Intermediate Processes below used in the elaboration of the problem statement; however, this is not an exhaustive list. Intermediate Aggregation Process An Intermediate Aggregation Process is an Intermediate Process that aggregates records based upon a set of Flow Keys, or functions applied to fields from the record (e.g. binning, subnet aggregation). Intermediate Correlation Process An Intermediate Correlation Process is an Intermediate Process which adds information to records noting correlations among them, or generates new records with correlated data from multiple records (e.g. the production of bidirectional flow records from unidirectional flow records). Intermediate Selection Process An Intermediate Selection Process is an Intermediate Process that selects records from a sequence based upon criteria evaluated record values, and passes only those records that match the criteria (e.g. filtering only records from a given network to a given Collector). Intermediate Anonymisation Process An Intermediate Anonymisation Process is an Intermediate Process that transforms records in order to anonymise them, to protect the identity of the entities described by the records (e.g. by applying prefix-preserving pseudonymisation of IP addresses). IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some data source, hosting zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Specific types of Mediators are defined below; some of these reference original mediation capabilities defined in earlier IPFIX documens before the elaboration of the Mediator problem statement. Original Exporter Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed. IPFIX Proxy An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX Messages or messages in other protocols to one or more Collectors. It can provide transport protocol mediation and re-encoding. IPFIX Concentrator An IPFIX Concentrator is an IPFIX Mediator that recieves data from one or more Exporters and sends them to a single Collector, optionally transforming the records using zero or more Intermediate Processes on the way. IPFIX Distributor An IPFIX Distributor is an IPFIX Mediator that recieves data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Selection Process. IPFIX Masquerading Proxy An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves data from one or more Exporters and sends them to a single Collector, using one or more Intermediate Aggregation Functions and Intermediate Anonymisation Functions to screen out parts of records according to configured policies, in order to protect the privacy of the network's end users or senstive data of the exporting organization. I think that we agree that the same terminology sections in both the problem statement and framework. Personally, I'm not sure (yet) if we need the Intermediate Aggregation/Correlation/Selection/Anonynisation Process. However, if we do, my proposal is to omit this list from the problem statement, and to simply put them in the framework. Please let us know, so that we can move forward with the drafts, both the problem statements and the framework. Regards, Benoit. From dressler@informatik.uni-erlangen.de Sat Jun 27 05:35:33 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880803A6ADC for ; Sat, 27 Jun 2009 05:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtrOuJ6VEC8N for ; Sat, 27 Jun 2009 05:35:32 -0700 (PDT) Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.34.45]) by core3.amsl.com (Postfix) with ESMTP id A05A83A68B8 for ; Sat, 27 Jun 2009 05:35:31 -0700 (PDT) Received: from faui7as (faui7as.informatik.uni-erlangen.de [131.188.37.230]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTPS id 5D72A4C55; Sat, 27 Jun 2009 14:35:49 +0200 (MEST) Received: from [192.168.178.37] (pD9E5EB63.dip.t-dialin.net [217.229.235.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7as (Postfix) with ESMTPSA id E764E4382A3; Sat, 27 Jun 2009 14:35:48 +0200 (CEST) Message-ID: <4A461218.7080307@informatik.uni-erlangen.de> Date: Sat, 27 Jun 2009 14:35:36 +0200 From: Falko Dressler User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Benoit Claise References: <4A44F660.1090300@cisco.com> In-Reply-To: <4A44F660.1090300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 12:35:33 -0000 Dear Benoit, many thanks for this summary. I think that covers the discussion quite well. > I think that we agree that the same terminology sections in both the > problem statement and framework. > Personally, I'm not sure (yet) if we need the Intermediate > Aggregation/Correlation/Selection/Anonynisation Process. > However, if we do, my proposal is to omit this list from the problem > statement, and to simply put them in the framework. > > Please let us know, so that we can move forward with the drafts, both > the problem statements and the framework. > Actually, I do think that these intermediate processes are very helpful to finally define more complex mediation systems. However, I agree to completely move them to the framework draft. Best regards, Falko -- Dr. Falko Dressler Computer Networks and Communication Systems University of Erlangen, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 mailto:dressler@informatik.uni-erlangen.de http://www7.informatik.uni-erlangen.de/~dressler/ From muenz@net.in.tum.de Sat Jun 27 06:51:46 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF3F3A6A6E for ; Sat, 27 Jun 2009 06:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, URIBL_RHS_DOB=1.083] 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 DSpUB0VM5NXK for ; Sat, 27 Jun 2009 06:51:44 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 51F8D3A6975 for ; Sat, 27 Jun 2009 06:51:43 -0700 (PDT) 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 CE9CB47D26; Sat, 27 Jun 2009 15:51:51 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id E440850D9; Sat, 27 Jun 2009 15:51:50 +0200 (CEST) Message-ID: <4A46244F.6070400@net.in.tum.de> Date: Sat, 27 Jun 2009 15:53:19 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Benoit Claise References: <4A44F660.1090300@cisco.com> In-Reply-To: <4A44F660.1090300@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000505030905020705060506" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 13:51:46 -0000 This is a cryptographically signed message in MIME format. --------------ms000505030905020705060506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Benoit, Thanks for the wrap up. I'm fine with this terminology. Just for clarification: An Original Exporter hosting an Intermediate Process is not an IPFIX Mediator according to your definition, right? s/recieve/receive Regards, Gerhard Benoit Claise wrote: > Dear all, >=20 > I'm trying to summarize the long email thread. Not easy, there are some= > diverging opinions. I hope I haven't forgotten anything > Below is the terminology proposal, based on Brian's proposal, improved > by Gerhard, and everybody. >=20 > 2. Terminology and Definitions >=20 > The terms in this section are in line with those in the IPFIX > Protocol specifications [RFC5101] and the PSAMP specification > document [RFC5476]. The terms Observation Point, Observation Domain,= > Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > Process, Transport Session, Information Element, and Template > Withdrawal Message, are defined in the IPFIX protocol specifications > [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > Device, and Configured Selection Fraction are defined in the PSAMP > specification document [RFC5476]. Furthermore, new terminology to be= > used in the context of IPFIX Mediation is defined in this section. > All these terms have an initial capital letter in this document. >=20 > In this document, we use the generic term "Data Records" for IPFIX > Flow Records, PSAMP Packet Reports, Data Records defined by Options > Templates, unless an explicit distinction is required. >=20 > Original Exporter >=20 > Original Exporter is an IPFIX Device that hosts the Observation > Points where the metered IP packets are observed. >=20 > IPFIX Mediation =20 > IPFIX Mediation describes the manipulation and conversion of recor= ds > for subsequent export using IPFIX, by applying mediation functions= > within one or more Intermediate Processes to a stream of records i= n > an IPFIX Mediator. >=20 > The following terms are used in this document to describe the > architectural entities used by IPFIX Mediation. >=20 > Intermediate Process >=20 > An Intermediate Process takes a sequence of records from a Collect= ing > Process, Metering Process, IPFIX File Reader, or another Intermedi= ate > Process within a Mediator; performs some transformation on these > records > based upon the content of the records themselves, state kept acros= s > multiple records, configuration parameters, or other data; and pas= ses > a sequence of transformed records on to an Exporting Process, IPFI= X > File > Writer, or another Intermediate Process within a Mediator. This > document > describes specific Intermediate Processes below used in the > elaboration > of the problem statement; however, this is not an exhaustive list.= >=20 > Intermediate Aggregation Process >=20 > An Intermediate Aggregation Process is an Intermediate Process that= > aggregates records based upon a set of Flow Keys, or functions > applied to fields from the record (e.g. binning, subnet aggregation= ). >=20 > Intermediate Correlation Process >=20 > An Intermediate Correlation Process is an Intermediate Process > which adds information to records noting correlations among them, > or generates new records with correlated data from multiple > records (e.g. the production of bidirectional flow records from > unidirectional flow records). >=20 > Intermediate Selection Process >=20 > An Intermediate Selection Process is an Intermediate Process that > selects records from a sequence based upon criteria evaluated > record values, and passes only those records that match the > criteria (e.g. filtering only records from a given network to a > given Collector). >=20 > Intermediate Anonymisation Process >=20 > An Intermediate Anonymisation Process is an Intermediate Process > that transforms records in order to anonymise them, to protect the= > identity of the entities described by the records (e.g. by > applying prefix-preserving pseudonymisation of IP addresses). >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some data source, hosting > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. Specific types of Mediators are defined > below; some of these reference original mediation capabilities > defined in earlier IPFIX documens before the elaboration of the > Mediator problem statement. >=20 > Original Exporter >=20 > Original Exporter is an IPFIX Device that hosts the Observation > Points where the metered IP packets are observed. >=20 > IPFIX Proxy >=20 > An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > Messages or messages in other protocols to one or more Collectors.= > It can provide transport protocol mediation and re-encoding. >=20 > IPFIX Concentrator >=20 > An IPFIX Concentrator is an IPFIX Mediator that recieves data from= > one or more Exporters and sends them to a single Collector, > optionally transforming the records using zero or more > Intermediate Processes on the way. >=20 > IPFIX Distributor >=20 > An IPFIX Distributor is an IPFIX Mediator that recieves data from > one or more Exporters and sends them to one or more Collectors, > deciding which Collector(s) to send each record to based upon the > decision of an Intermediate Selection Process. >=20 > IPFIX Masquerading Proxy >=20 > An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > data from one or more Exporters and sends them to a single > Collector, using one or more Intermediate Aggregation Functions > and Intermediate Anonymisation Functions to screen out parts of > records according to configured policies, in order to protect the > privacy of the network's end users or senstive data of the > exporting organization. >=20 >=20 > I think that we agree that the same terminology sections in both the > problem statement and framework. > Personally, I'm not sure (yet) if we need the Intermediate > Aggregation/Correlation/Selection/Anonynisation Process. > However, if we do, my proposal is to omit this list from the problem > statement, and to simply put them in the framework. >=20 > Please let us know, so that we can move forward with the drafts, both > the problem statements and the framework. >=20 > Regards, Benoit. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 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 --------------ms000505030905020705060506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjI3MTM1MzE5WjAjBgkqhkiG9w0BCQQxFgQU 6NoLfpFp0442Tbsbj9xzQJZ6pLcwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAFBa3n7DizB1q6/FDj1I4zV6nLTCJicZI6AgD+MFfJl9oFQs ZGa6/SUsvhbXDqKmWUNj87KmPODgt2jYGmcDn8vjjJF29AMtS08/YOGA8TZtMPQ6stTFUYjy VADAxuy9RPgXY6EpNLJk6h+D3bYPJrvFdeiR2MxsFQjHqq6msXKMSzo3vBzRmxSVQwigtbnQ 8VrFCjSVtcK6WU2vbYGCg/ftmhTnXtaIfSFdZeeb207o1NPJGsm/au8YfKaxFLBtnyGMIBfV EEqMwrwQczhEGvmnwvIc5jn4lPlk1XwXslaAO21RuCen+HYWsGZLjlzq871+d11SUMLebGDx rEBLJVAAAAAAAAA= --------------ms000505030905020705060506-- From akoba@nttv6.net Sun Jun 28 18:58:01 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4323A68C9 for ; Sun, 28 Jun 2009 18:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 ZzdYGeQTDukL for ; Sun, 28 Jun 2009 18:58:00 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id B18D53A67E2 for ; Sun, 28 Jun 2009 18:57:59 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:514f:5228:b7e5:6a04]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5T1vA5v070754; Mon, 29 Jun 2009 10:57:11 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 29 Jun 2009 10:53:19 +0900 From: Atsushi Kobayashi To: Falko Dressler In-Reply-To: <4A461218.7080307@informatik.uni-erlangen.de> References: <4A44F660.1090300@cisco.com> <4A461218.7080307@informatik.uni-erlangen.de> Message-Id: <20090629104807.3A4D.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 29 Jun 2009 10:57:11 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:58:01 -0000 Hi Falko and all, On Sat, 27 Jun 2009 14:35:36 +0200 Falko Dressler wrote: > Dear Benoit, > > many thanks for this summary. I think that covers the discussion quite well. > > > I think that we agree that the same terminology sections in both the > > problem statement and framework. > > Personally, I'm not sure (yet) if we need the Intermediate > > Aggregation/Correlation/Selection/Anonynisation Process. > > However, if we do, my proposal is to omit this list from the problem > > statement, and to simply put them in the framework. > > > > Please let us know, so that we can move forward with the drafts, both > > the problem statements and the framework. > > > > Actually, I do think that these intermediate processes are very helpful > to finally define more complex mediation systems. However, I agree to > completely move them to the framework draft. > I agree to move them to the framework draft. If we omit the Intermediate Aggregation/Correlation/Selection/Anonynisation Process, we need to modify the IPFIX Distributor/Masquerading Proxy referring to the Intermediate FOO Process . IPFIX Distributor An IPFIX Distributor is an IPFIX Mediator that recieves data from one or more Exporters and sends them to one or more Collectors, deciding which Collector(s) to send each record to based upon the decision of an Intermediate Process. ~~~~~~~~~~~~~~~~~~~~~ IPFIX Masquerading Proxy An IPFIX Masquerading Proxy is an IPFIX Mediator that receives data from one or more Exporters and sends them to a single Collector, using one or more records aggregation functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and anonymisation functions to screen out parts of ~~~~~~~~~~~~~~~~~~~~~~~ records according to configured policies, in order to protect the privacy of the network's end users or senstive data of the exporting organization. Is it OK? Regards, Atsushi > Best regards, > Falko > > -- > Dr. Falko Dressler > Computer Networks and Communication Systems > University of Erlangen, Germany > Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 > mailto:dressler@informatik.uni-erlangen.de > http://www7.informatik.uni-erlangen.de/~dressler/ > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From trammell@tik.ee.ethz.ch Sun Jun 28 23:30:40 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAB43A6B5E for ; Sun, 28 Jun 2009 23:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5CGuRH6rTmE for ; Sun, 28 Jun 2009 23:30:39 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 3E5F33A681F for ; Sun, 28 Jun 2009 23:30:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C1C64D9367; Mon, 29 Jun 2009 08:30:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nSozjsdriAHO; Mon, 29 Jun 2009 08:30:56 +0200 (MEST) Received: from [10.0.1.11] (84-75-172-247.dclient.hispeed.ch [84.75.172.247]) (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 33C38D931C; Mon, 29 Jun 2009 08:30:56 +0200 (MEST) Message-Id: <536C9568-D037-43D1-A2F7-842D271657A4@tik.ee.ethz.ch> From: Brian Trammell To: Atsushi Kobayashi In-Reply-To: <20090629104807.3A4D.17391CF2@nttv6.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 08:30:55 +0200 References: <4A44F660.1090300@cisco.com> <4A461218.7080307@informatik.uni-erlangen.de> <20090629104807.3A4D.17391CF2@nttv6.net> X-Mailer: Apple Mail (2.935.3) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 06:30:40 -0000 Hi all, (returned from holidays, still catching up on the thread, but have the following quick point to make...) actually, there's something weird here, in that we switch from Intermediate Foo Processes to Intermediate Foo Functions when talking about the Masquerading Proxy. We should stick with Processes (since we're defining them), I think. At this level, then, I would suggest the following: IPFIX Masquerading Proxy An IPFIX Masquerading Proxy is an IPFIX Mediator that receives data from one or more Exporters and sends them to a single Collector, using one or more Intermediate Processes to screen out parts of ~~~~~~~~~~~~~~~~~~~~~~ records according to configured policies, in order to protect the privacy of the network's end users or senstive data of the exporting organization. Cheers, Brian On Jun 29, 2009, at 3:53 AM, Atsushi Kobayashi wrote: > > Hi Falko and all, > > On Sat, 27 Jun 2009 14:35:36 +0200 > Falko Dressler wrote: > >> Dear Benoit, >> >> many thanks for this summary. I think that covers the discussion >> quite well. >> >>> I think that we agree that the same terminology sections in both the >>> problem statement and framework. >>> Personally, I'm not sure (yet) if we need the Intermediate >>> Aggregation/Correlation/Selection/Anonynisation Process. >>> However, if we do, my proposal is to omit this list from the problem >>> statement, and to simply put them in the framework. >>> >>> Please let us know, so that we can move forward with the drafts, >>> both >>> the problem statements and the framework. >>> >> >> Actually, I do think that these intermediate processes are very >> helpful >> to finally define more complex mediation systems. However, I agree to >> completely move them to the framework draft. >> > > I agree to move them to the framework draft. > > If we omit the Intermediate Aggregation/Correlation/Selection/ > Anonynisation > Process, we need to modify the IPFIX Distributor/Masquerading Proxy > referring > to the Intermediate FOO Process . > > IPFIX Distributor > > An IPFIX Distributor is an IPFIX Mediator that recieves data > from > one or more Exporters and sends them to one or more Collectors, > deciding which Collector(s) to send each record to based upon > the > decision of an Intermediate Process. > ~~~~~~~~~~~~~~~~~~~~~ > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that receives > data from one or more Exporters and sends them to a single > Collector, using one or more records aggregation functions > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > and anonymisation functions to screen out parts of > ~~~~~~~~~~~~~~~~~~~~~~~ > records according to configured policies, in order to protect > the > privacy of the network's end users or senstive data of the > exporting organization. > > Is it OK? > > Regards, > Atsushi > >> Best regards, >> Falko >> >> -- >> Dr. Falko Dressler >> Computer Networks and Communication Systems >> University of Erlangen, Germany >> Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 >> mailto:dressler@informatik.uni-erlangen.de >> http://www7.informatik.uni-erlangen.de/~dressler/ >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --- > 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 akoba@nttv6.net Mon Jun 29 00:51:14 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B6128C187 for ; Mon, 29 Jun 2009 00:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 6awHJcaryxnf for ; Mon, 29 Jun 2009 00:51:12 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 9C3CE28C169 for ; Mon, 29 Jun 2009 00:51:11 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:1c6b:3899:3a76:6a20]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5T7pPUx072457; Mon, 29 Jun 2009 16:51:28 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 29 Jun 2009 16:47:35 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A46244F.6070400@net.in.tum.de> References: <4A44F660.1090300@cisco.com> <4A46244F.6070400@net.in.tum.de> Message-Id: <20090629155310.3A56.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 29 Jun 2009 16:51:28 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 07:51:14 -0000 Hi Gerhard and all, The definition implies that the Original Exporter hosting IP is not IPFIX Mediator. Because it mentions that the IPFIX Mediator receives records from some data source. To clarify, do we need to modify as follows? IPFIX Mediator An IPFIX Mediator is an IPFIX Device that provides mediation capabilities by receiving records from some exporting device, hosting ^^^^^^^^^^^^^^^^^^^^^ zero or more Intermediate Processes to transform those records, and exporting those records in IPFIX Messages via an Exporting Process. In the common case, a Mediator receives records from a Collecting Process, but could also receive records from data sources not encoded using IPFIX, e.g., in the case of NetFlow V9 protocol translation. Specific types of Mediators are defined below; some of these reference original mediation capabilities defined in earlier IPFIX documens before the elaboration of the Mediator problem statement. Regards, Atsushi On Sat, 27 Jun 2009 15:53:19 +0200 Gerhard Muenz wrote: > > Hi Benoit, > > Thanks for the wrap up. I'm fine with this terminology. > > Just for clarification: > An Original Exporter hosting an Intermediate Process is not an IPFIX > Mediator according to your definition, right? > > s/recieve/receive > > Regards, > Gerhard > > > Benoit Claise wrote: > > Dear all, > > > > I'm trying to summarize the long email thread. Not easy, there are some > > diverging opinions. I hope I haven't forgotten anything > > Below is the terminology proposal, based on Brian's proposal, improved > > by Gerhard, and everybody. > > > > 2. Terminology and Definitions > > > > The terms in this section are in line with those in the IPFIX > > Protocol specifications [RFC5101] and the PSAMP specification > > document [RFC5476]. The terms Observation Point, Observation Domain, > > Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > > IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > > Process, Transport Session, Information Element, and Template > > Withdrawal Message, are defined in the IPFIX protocol specifications > > [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > > Device, and Configured Selection Fraction are defined in the PSAMP > > specification document [RFC5476]. Furthermore, new terminology to be > > used in the context of IPFIX Mediation is defined in this section. > > All these terms have an initial capital letter in this document. > > > > In this document, we use the generic term "Data Records" for IPFIX > > Flow Records, PSAMP Packet Reports, Data Records defined by Options > > Templates, unless an explicit distinction is required. > > > > Original Exporter > > > > Original Exporter is an IPFIX Device that hosts the Observation > > Points where the metered IP packets are observed. > > > > IPFIX Mediation > > IPFIX Mediation describes the manipulation and conversion of records > > for subsequent export using IPFIX, by applying mediation functions > > within one or more Intermediate Processes to a stream of records in > > an IPFIX Mediator. > > > > The following terms are used in this document to describe the > > architectural entities used by IPFIX Mediation. > > > > Intermediate Process > > > > An Intermediate Process takes a sequence of records from a Collecting > > Process, Metering Process, IPFIX File Reader, or another Intermediate > > Process within a Mediator; performs some transformation on these > > records > > based upon the content of the records themselves, state kept across > > multiple records, configuration parameters, or other data; and passes > > a sequence of transformed records on to an Exporting Process, IPFIX > > File > > Writer, or another Intermediate Process within a Mediator. This > > document > > describes specific Intermediate Processes below used in the > > elaboration > > of the problem statement; however, this is not an exhaustive list. > > > > Intermediate Aggregation Process > > > > An Intermediate Aggregation Process is an Intermediate Process that > > aggregates records based upon a set of Flow Keys, or functions > > applied to fields from the record (e.g. binning, subnet aggregation). > > > > Intermediate Correlation Process > > > > An Intermediate Correlation Process is an Intermediate Process > > which adds information to records noting correlations among them, > > or generates new records with correlated data from multiple > > records (e.g. the production of bidirectional flow records from > > unidirectional flow records). > > > > Intermediate Selection Process > > > > An Intermediate Selection Process is an Intermediate Process that > > selects records from a sequence based upon criteria evaluated > > record values, and passes only those records that match the > > criteria (e.g. filtering only records from a given network to a > > given Collector). > > > > Intermediate Anonymisation Process > > > > An Intermediate Anonymisation Process is an Intermediate Process > > that transforms records in order to anonymise them, to protect the > > identity of the entities described by the records (e.g. by > > applying prefix-preserving pseudonymisation of IP addresses). > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides mediation > > capabilities by receiving records from some data source, hosting > > zero or more Intermediate Processes to transform those records, > > and exporting those records in IPFIX Messages via an Exporting > > Process. In the common case, a Mediator receives records from a > > Collecting Process, but could also receive records from data > > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > > protocol translation. Specific types of Mediators are defined > > below; some of these reference original mediation capabilities > > defined in earlier IPFIX documens before the elaboration of the > > Mediator problem statement. > > > > Original Exporter > > > > Original Exporter is an IPFIX Device that hosts the Observation > > Points where the metered IP packets are observed. > > > > IPFIX Proxy > > > > An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > > Messages or messages in other protocols to one or more Collectors. > > It can provide transport protocol mediation and re-encoding. > > > > IPFIX Concentrator > > > > An IPFIX Concentrator is an IPFIX Mediator that recieves data from > > one or more Exporters and sends them to a single Collector, > > optionally transforming the records using zero or more > > Intermediate Processes on the way. > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that recieves data from > > one or more Exporters and sends them to one or more Collectors, > > deciding which Collector(s) to send each record to based upon the > > decision of an Intermediate Selection Process. > > > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > > data from one or more Exporters and sends them to a single > > Collector, using one or more Intermediate Aggregation Functions > > and Intermediate Anonymisation Functions to screen out parts of > > records according to configured policies, in order to protect the > > privacy of the network's end users or senstive data of the > > exporting organization. > > > > > > I think that we agree that the same terminology sections in both the > > problem statement and framework. > > Personally, I'm not sure (yet) if we need the Intermediate > > Aggregation/Correlation/Selection/Anonynisation Process. > > However, if we do, my proposal is to omit this list from the problem > > statement, and to simply put them in the framework. > > > > Please let us know, so that we can move forward with the drafts, both > > the problem statements and the framework. > > > > Regards, Benoit. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > -- > Dipl.-Ing. Gerhard M > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universitchen > Boltzmannstr. 3, 85748 Garching bei Mchen, 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 NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Mon Jun 29 01:03:49 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B732D28C12A for ; Mon, 29 Jun 2009 01:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.816, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdPXTKupyDBQ for ; Mon, 29 Jun 2009 01:03:48 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 03AA928C0E1 for ; Mon, 29 Jun 2009 01:03:48 -0700 (PDT) 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 3AD88485EF; Mon, 29 Jun 2009 10:04:02 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 851FFA24; Mon, 29 Jun 2009 10:04:01 +0200 (CEST) Message-ID: <4A4875D1.80006@net.in.tum.de> Date: Mon, 29 Jun 2009 10:05:37 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <4A44F660.1090300@cisco.com> <4A46244F.6070400@net.in.tum.de> <20090629155310.3A56.17391CF2@nttv6.net> In-Reply-To: <20090629155310.3A56.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030100060309080301030605" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:03:49 -0000 This is a cryptographically signed message in MIME format. --------------ms030100060309080301030605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Hi Gerhard and all, >=20 > The definition implies that the Original Exporter hosting IP is not > IPFIX Mediator. Because it mentions that the IPFIX Mediator receives > records from some data source. This is how I understood the terminology. My question was if this is intended. > To clarify, do we need to modify as follows? >=20 > IPFIX Mediator >=20 > An IPFIX Mediator is an IPFIX Device that provides mediation > capabilities by receiving records from some exporting device, hos= ting > ^^^^^^^^^^^^^^^^^^^^^ > zero or more Intermediate Processes to transform those records, > and exporting those records in IPFIX Messages via an Exporting > Process. In the common case, a Mediator receives records from a > Collecting Process, but could also receive records from data > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > protocol translation. Specific types of Mediators are defined > below; some of these reference original mediation capabilities > defined in earlier IPFIX documens before the elaboration of the > Mediator problem statement. No. If you want to clarify something, you could add a sentence to the IP definition, for example: Intermediate Process ... Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Gerhard >=20 > Regards, > Atsushi >=20 > On Sat, 27 Jun 2009 15:53:19 +0200 > Gerhard Muenz wrote: >=20 >> Hi Benoit, >> >> Thanks for the wrap up. I'm fine with this terminology. >> >> Just for clarification: >> An Original Exporter hosting an Intermediate Process is not an IPFIX >> Mediator according to your definition, right? >> >> s/recieve/receive >> >> Regards, >> Gerhard >> >> >> Benoit Claise wrote: >>> Dear all, >>> >>> I'm trying to summarize the long email thread. Not easy, there are so= me >>> diverging opinions. I hope I haven't forgotten anything >>> Below is the terminology proposal, based on Brian's proposal, improve= d >>> by Gerhard, and everybody. >>> >>> 2. Terminology and Definitions >>> >>> The terms in this section are in line with those in the IPFIX >>> Protocol specifications [RFC5101] and the PSAMP specification >>> document [RFC5476]. The terms Observation Point, Observation Domai= n, >>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, >>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Meterin= g >>> Process, Transport Session, Information Element, and Template >>> Withdrawal Message, are defined in the IPFIX protocol specification= s >>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP >>> Device, and Configured Selection Fraction are defined in the PSAMP >>> specification document [RFC5476]. Furthermore, new terminology to = be >>> used in the context of IPFIX Mediation is defined in this section. >>> All these terms have an initial capital letter in this document. >>> >>> In this document, we use the generic term "Data Records" for IPFIX >>> Flow Records, PSAMP Packet Reports, Data Records defined by Options= >>> Templates, unless an explicit distinction is required. >>> >>> Original Exporter >>> >>> Original Exporter is an IPFIX Device that hosts the Observation >>> Points where the metered IP packets are observed. >>> >>> IPFIX Mediation =20 >>> IPFIX Mediation describes the manipulation and conversion of rec= ords >>> for subsequent export using IPFIX, by applying mediation functio= ns >>> within one or more Intermediate Processes to a stream of records= in >>> an IPFIX Mediator. >>> >>> The following terms are used in this document to describe the >>> architectural entities used by IPFIX Mediation. >>> >>> Intermediate Process >>> >>> An Intermediate Process takes a sequence of records from a Colle= cting >>> Process, Metering Process, IPFIX File Reader, or another Interme= diate >>> Process within a Mediator; performs some transformation on these= >>> records >>> based upon the content of the records themselves, state kept acr= oss >>> multiple records, configuration parameters, or other data; and p= asses >>> a sequence of transformed records on to an Exporting Process, IP= FIX >>> File >>> Writer, or another Intermediate Process within a Mediator. This >>> document >>> describes specific Intermediate Processes below used in the >>> elaboration >>> of the problem statement; however, this is not an exhaustive lis= t. >>> >>> Intermediate Aggregation Process >>> >>> An Intermediate Aggregation Process is an Intermediate Process th= at >>> aggregates records based upon a set of Flow Keys, or functions >>> applied to fields from the record (e.g. binning, subnet aggregati= on). >>> >>> Intermediate Correlation Process >>> >>> An Intermediate Correlation Process is an Intermediate Process >>> which adds information to records noting correlations among them= , >>> or generates new records with correlated data from multiple >>> records (e.g. the production of bidirectional flow records from >>> unidirectional flow records). >>> >>> Intermediate Selection Process >>> >>> An Intermediate Selection Process is an Intermediate Process tha= t >>> selects records from a sequence based upon criteria evaluated >>> record values, and passes only those records that match the >>> criteria (e.g. filtering only records from a given network to a >>> given Collector). >>> >>> Intermediate Anonymisation Process >>> >>> An Intermediate Anonymisation Process is an Intermediate Process= >>> that transforms records in order to anonymise them, to protect t= he >>> identity of the entities described by the records (e.g. by >>> applying prefix-preserving pseudonymisation of IP addresses). >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some data source, hosting= >>> zero or more Intermediate Processes to transform those records, >>> and exporting those records in IPFIX Messages via an Exporting >>> Process. In the common case, a Mediator receives records from a= >>> Collecting Process, but could also receive records from data >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9= >>> protocol translation. Specific types of Mediators are defined >>> below; some of these reference original mediation capabilities >>> defined in earlier IPFIX documens before the elaboration of the >>> Mediator problem statement. >>> >>> Original Exporter >>> >>> Original Exporter is an IPFIX Device that hosts the Observation >>> Points where the metered IP packets are observed. >>> >>> IPFIX Proxy >>> >>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX >>> Messages or messages in other protocols to one or more Collector= s. >>> It can provide transport protocol mediation and re-encoding. >>> >>> IPFIX Concentrator >>> >>> An IPFIX Concentrator is an IPFIX Mediator that recieves data fr= om >>> one or more Exporters and sends them to a single Collector, >>> optionally transforming the records using zero or more >>> Intermediate Processes on the way. >>> >>> IPFIX Distributor >>> >>> An IPFIX Distributor is an IPFIX Mediator that recieves data fro= m >>> one or more Exporters and sends them to one or more Collectors, >>> deciding which Collector(s) to send each record to based upon th= e >>> decision of an Intermediate Selection Process. >>> >>> IPFIX Masquerading Proxy >>> >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves >>> data from one or more Exporters and sends them to a single >>> Collector, using one or more Intermediate Aggregation Functions >>> and Intermediate Anonymisation Functions to screen out parts of >>> records according to configured policies, in order to protect th= e >>> privacy of the network's end users or senstive data of the >>> exporting organization. >>> >>> >>> I think that we agree that the same terminology sections in both the >>> problem statement and framework. >>> Personally, I'm not sure (yet) if we need the Intermediate >>> Aggregation/Correlation/Selection/Anonynisation Process. >>> However, if we do, my proposal is to omit this list from the problem >>> statement, and to simply put them in the framework. >>> >>> Please let us know, so that we can move forward with the drafts, both= >>> the problem statements and the framework. >>> >>> Regards, Benoit. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >> --=20 >> Dipl.-Ing. Gerhard M >> Chair for Network Architectures and Services (I8) >> Department of Informatics >> Technische Universitchen >> Boltzmannstr. 3, 85748 Garching bei Mchen, 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 > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=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 --------------ms030100060309080301030605 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjI5MDgwNTM3WjAjBgkqhkiG9w0BCQQxFgQU yT3g99tBKhsGc5hVWmgLmzwgkyUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBALWJARDCZnj2J5A2ozBrHh4T9dbmgRPm0Ffg75FT2p1myYVO a1dXIX/7IBI37jCWD9akSz6T8qUyNMhmS9MxjSvA4bSFTptdwymlatXllW98VesuxABBlP+g nFLbM3LZ86MToZcqYaKP5fG0yD0/nZb1XSmTPFTrmkK+NQDyaychY0jHA1zPRoso4dagDS2y 6cwNJQZYJ7aHViygqFLO0+XpFKjaZGHbougWgehtOp2W0XXLwlOgAvOvqY2TCmjDSPxEdkxT 8TXhSp/BzdAprIZgL7EAMAcG9Zy2vTI6YX7cZwGxVW4XU7G/e9oZypp78tMVXjak6WYiqfuE 4d9pgqkAAAAAAAA= --------------ms030100060309080301030605-- From akoba@nttv6.net Mon Jun 29 01:08:41 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2F828C18E for ; Mon, 29 Jun 2009 01:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 zz418-3KgaRQ for ; Mon, 29 Jun 2009 01:08:41 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 8CE6128C189 for ; Mon, 29 Jun 2009 01:08:40 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:1c6b:3899:3a76:6a20]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5T88uEE072549; Mon, 29 Jun 2009 17:08:57 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 29 Jun 2009 17:05:06 +0900 From: Atsushi Kobayashi To: Brian Trammell In-Reply-To: <536C9568-D037-43D1-A2F7-842D271657A4@tik.ee.ethz.ch> References: <20090629104807.3A4D.17391CF2@nttv6.net> <536C9568-D037-43D1-A2F7-842D271657A4@tik.ee.ethz.ch> Message-Id: <20090629165625.3A59.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 29 Jun 2009 17:08:59 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:08:42 -0000 Hi Brian and all, Your suggestion is fine for me. Thus, just Intermediate FOO Processes can move to framework draft. Regards, Atsushi On Mon, 29 Jun 2009 08:30:55 +0200 Brian Trammell wrote: > Hi all, > > (returned from holidays, still catching up on the thread, but have the > following quick point to make...) > > actually, there's something weird here, in that we switch from > Intermediate Foo Processes to Intermediate Foo Functions when talking > about the Masquerading Proxy. We should stick with Processes (since > we're defining them), I think. At this level, then, I would suggest > the following: > > IPFIX Masquerading Proxy > > An IPFIX Masquerading Proxy is an IPFIX Mediator that receives > data from one or more Exporters and sends them to a single > Collector, using one or more Intermediate Processes to screen > out parts of > ~~~~~~~~~~~~~~~~~~~~~~ > records according to configured policies, in order to protect the > privacy of the network's end users or senstive data of the > exporting organization. > > Cheers, > > Brian > > On Jun 29, 2009, at 3:53 AM, Atsushi Kobayashi wrote: > > > > > Hi Falko and all, > > > > On Sat, 27 Jun 2009 14:35:36 +0200 > > Falko Dressler wrote: > > > >> Dear Benoit, > >> > >> many thanks for this summary. I think that covers the discussion > >> quite well. > >> > >>> I think that we agree that the same terminology sections in both the > >>> problem statement and framework. > >>> Personally, I'm not sure (yet) if we need the Intermediate > >>> Aggregation/Correlation/Selection/Anonynisation Process. > >>> However, if we do, my proposal is to omit this list from the problem > >>> statement, and to simply put them in the framework. > >>> > >>> Please let us know, so that we can move forward with the drafts, > >>> both > >>> the problem statements and the framework. > >>> > >> > >> Actually, I do think that these intermediate processes are very > >> helpful > >> to finally define more complex mediation systems. However, I agree to > >> completely move them to the framework draft. > >> > > > > I agree to move them to the framework draft. > > > > If we omit the Intermediate Aggregation/Correlation/Selection/ > > Anonynisation > > Process, we need to modify the IPFIX Distributor/Masquerading Proxy > > referring > > to the Intermediate FOO Process . > > > > IPFIX Distributor > > > > An IPFIX Distributor is an IPFIX Mediator that recieves data > > from > > one or more Exporters and sends them to one or more Collectors, > > deciding which Collector(s) to send each record to based upon > > the > > decision of an Intermediate Process. > > ~~~~~~~~~~~~~~~~~~~~~ > > IPFIX Masquerading Proxy > > > > An IPFIX Masquerading Proxy is an IPFIX Mediator that receives > > data from one or more Exporters and sends them to a single > > Collector, using one or more records aggregation functions > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > and anonymisation functions to screen out parts of > > ~~~~~~~~~~~~~~~~~~~~~~~ > > records according to configured policies, in order to protect > > the > > privacy of the network's end users or senstive data of the > > exporting organization. > > > > Is it OK? > > > > Regards, > > Atsushi > > > >> Best regards, > >> Falko > >> > >> -- > >> Dr. Falko Dressler > >> Computer Networks and Communication Systems > >> University of Erlangen, Germany > >> Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 > >> mailto:dressler@informatik.uni-erlangen.de > >> http://www7.informatik.uni-erlangen.de/~dressler/ > >> _______________________________________________ > >> IPFIX mailing list > >> IPFIX@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipfix > > > > --- > > 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 > --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Mon Jun 29 01:57:42 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7E928C1CB for ; Mon, 29 Jun 2009 01:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 tA1BImwMKuSx for ; Mon, 29 Jun 2009 01:57:41 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id C2C0828C1BA for ; Mon, 29 Jun 2009 01:57:40 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:1c6b:3899:3a76:6a20]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5T8vpv0072805; Mon, 29 Jun 2009 17:57:54 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 29 Jun 2009 17:54:00 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A4875D1.80006@net.in.tum.de> References: <20090629155310.3A56.17391CF2@nttv6.net> <4A4875D1.80006@net.in.tum.de> Message-Id: <20090629174637.3A64.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 29 Jun 2009 17:57:54 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:57:42 -0000 Hi Gerhard and all, Yes, it is more important that Original Exporter can host Intermediate Process. Your suggestion is fine for me. However, Intermediate Process definition already uses term "IPFIX Mediator" in previous paragraph. There is little bit strange if just your proposal is put in it. I would like to modify it as follows. Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process within a same device; performs some transformation on these records ^^^^^^^^^^^^ based upon the content of the records themselves, state kept across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Process within a same device. ^^^^^^^^^^^^^ Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Does it make sense? Regards, Atsushi On Mon, 29 Jun 2009 10:05:37 +0200 Gerhard Muenz wrote: > > Hi Atsushi, > > Atsushi Kobayashi wrote: > > Hi Gerhard and all, > > > > The definition implies that the Original Exporter hosting IP is not > > IPFIX Mediator. Because it mentions that the IPFIX Mediator receives > > records from some data source. > > This is how I understood the terminology. > My question was if this is intended. > > > To clarify, do we need to modify as follows? > > > > IPFIX Mediator > > > > An IPFIX Mediator is an IPFIX Device that provides mediation > > capabilities by receiving records from some exporting device, hosting > > ^^^^^^^^^^^^^^^^^^^^^ > > zero or more Intermediate Processes to transform those records, > > and exporting those records in IPFIX Messages via an Exporting > > Process. In the common case, a Mediator receives records from a > > Collecting Process, but could also receive records from data > > sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > > protocol translation. Specific types of Mediators are defined > > below; some of these reference original mediation capabilities > > defined in earlier IPFIX documens before the elaboration of the > > Mediator problem statement. > > No. > > If you want to clarify something, you could add a sentence to the IP > definition, for example: > > Intermediate Process > ... > Typically, an Intermediate Process is hosted by an IPFIX Mediator. > Alternatively, an Intermediate Process may be hosted by an Original > Exporter. > > Gerhard > > > > > > Regards, > > Atsushi > > > > On Sat, 27 Jun 2009 15:53:19 +0200 > > Gerhard Muenz wrote: > > > >> Hi Benoit, > >> > >> Thanks for the wrap up. I'm fine with this terminology. > >> > >> Just for clarification: > >> An Original Exporter hosting an Intermediate Process is not an IPFIX > >> Mediator according to your definition, right? > >> > >> s/recieve/receive > >> > >> Regards, > >> Gerhard > >> > >> > >> Benoit Claise wrote: > >>> Dear all, > >>> > >>> I'm trying to summarize the long email thread. Not easy, there are some > >>> diverging opinions. I hope I haven't forgotten anything > >>> Below is the terminology proposal, based on Brian's proposal, improved > >>> by Gerhard, and everybody. > >>> > >>> 2. Terminology and Definitions > >>> > >>> The terms in this section are in line with those in the IPFIX > >>> Protocol specifications [RFC5101] and the PSAMP specification > >>> document [RFC5476]. The terms Observation Point, Observation Domain, > >>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, > >>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Metering > >>> Process, Transport Session, Information Element, and Template > >>> Withdrawal Message, are defined in the IPFIX protocol specifications > >>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP > >>> Device, and Configured Selection Fraction are defined in the PSAMP > >>> specification document [RFC5476]. Furthermore, new terminology to be > >>> used in the context of IPFIX Mediation is defined in this section. > >>> All these terms have an initial capital letter in this document. > >>> > >>> In this document, we use the generic term "Data Records" for IPFIX > >>> Flow Records, PSAMP Packet Reports, Data Records defined by Options > >>> Templates, unless an explicit distinction is required. > >>> > >>> Original Exporter > >>> > >>> Original Exporter is an IPFIX Device that hosts the Observation > >>> Points where the metered IP packets are observed. > >>> > >>> IPFIX Mediation > >>> IPFIX Mediation describes the manipulation and conversion of records > >>> for subsequent export using IPFIX, by applying mediation functions > >>> within one or more Intermediate Processes to a stream of records in > >>> an IPFIX Mediator. > >>> > >>> The following terms are used in this document to describe the > >>> architectural entities used by IPFIX Mediation. > >>> > >>> Intermediate Process > >>> > >>> An Intermediate Process takes a sequence of records from a Collecting > >>> Process, Metering Process, IPFIX File Reader, or another Intermediate > >>> Process within a Mediator; performs some transformation on these > >>> records > >>> based upon the content of the records themselves, state kept across > >>> multiple records, configuration parameters, or other data; and passes > >>> a sequence of transformed records on to an Exporting Process, IPFIX > >>> File > >>> Writer, or another Intermediate Process within a Mediator. This > >>> document > >>> describes specific Intermediate Processes below used in the > >>> elaboration > >>> of the problem statement; however, this is not an exhaustive list. > >>> > >>> Intermediate Aggregation Process > >>> > >>> An Intermediate Aggregation Process is an Intermediate Process that > >>> aggregates records based upon a set of Flow Keys, or functions > >>> applied to fields from the record (e.g. binning, subnet aggregation). > >>> > >>> Intermediate Correlation Process > >>> > >>> An Intermediate Correlation Process is an Intermediate Process > >>> which adds information to records noting correlations among them, > >>> or generates new records with correlated data from multiple > >>> records (e.g. the production of bidirectional flow records from > >>> unidirectional flow records). > >>> > >>> Intermediate Selection Process > >>> > >>> An Intermediate Selection Process is an Intermediate Process that > >>> selects records from a sequence based upon criteria evaluated > >>> record values, and passes only those records that match the > >>> criteria (e.g. filtering only records from a given network to a > >>> given Collector). > >>> > >>> Intermediate Anonymisation Process > >>> > >>> An Intermediate Anonymisation Process is an Intermediate Process > >>> that transforms records in order to anonymise them, to protect the > >>> identity of the entities described by the records (e.g. by > >>> applying prefix-preserving pseudonymisation of IP addresses). > >>> > >>> IPFIX Mediator > >>> > >>> An IPFIX Mediator is an IPFIX Device that provides mediation > >>> capabilities by receiving records from some data source, hosting > >>> zero or more Intermediate Processes to transform those records, > >>> and exporting those records in IPFIX Messages via an Exporting > >>> Process. In the common case, a Mediator receives records from a > >>> Collecting Process, but could also receive records from data > >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V9 > >>> protocol translation. Specific types of Mediators are defined > >>> below; some of these reference original mediation capabilities > >>> defined in earlier IPFIX documens before the elaboration of the > >>> Mediator problem statement. > >>> > >>> Original Exporter > >>> > >>> Original Exporter is an IPFIX Device that hosts the Observation > >>> Points where the metered IP packets are observed. > >>> > >>> IPFIX Proxy > >>> > >>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX > >>> Messages or messages in other protocols to one or more Collectors. > >>> It can provide transport protocol mediation and re-encoding. > >>> > >>> IPFIX Concentrator > >>> > >>> An IPFIX Concentrator is an IPFIX Mediator that recieves data from > >>> one or more Exporters and sends them to a single Collector, > >>> optionally transforming the records using zero or more > >>> Intermediate Processes on the way. > >>> > >>> IPFIX Distributor > >>> > >>> An IPFIX Distributor is an IPFIX Mediator that recieves data from > >>> one or more Exporters and sends them to one or more Collectors, > >>> deciding which Collector(s) to send each record to based upon the > >>> decision of an Intermediate Selection Process. > >>> > >>> IPFIX Masquerading Proxy > >>> > >>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves > >>> data from one or more Exporters and sends them to a single > >>> Collector, using one or more Intermediate Aggregation Functions > >>> and Intermediate Anonymisation Functions to screen out parts of > >>> records according to configured policies, in order to protect the > >>> privacy of the network's end users or senstive data of the > >>> exporting organization. > >>> > >>> > >>> I think that we agree that the same terminology sections in both the > >>> problem statement and framework. > >>> Personally, I'm not sure (yet) if we need the Intermediate > >>> Aggregation/Correlation/Selection/Anonynisation Process. > >>> However, if we do, my proposal is to omit this list from the problem > >>> statement, and to simply put them in the framework. > >>> > >>> Please let us know, so that we can move forward with the drafts, both > >>> the problem statements and the framework. > >>> > >>> Regards, Benoit. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Mon Jun 29 02:38:03 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CB93A6D6B for ; Mon, 29 Jun 2009 02:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.773, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHv+BpZXWujZ for ; Mon, 29 Jun 2009 02:38:02 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 1163B3A6D68 for ; Mon, 29 Jun 2009 02:38:01 -0700 (PDT) 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 1CA3A485EF; Mon, 29 Jun 2009 11:38:12 +0200 (CEST) Received: from [131.159.20.249] (vpn-3.net.informatik.tu-muenchen.de [131.159.20.249]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 22A6B509D; Mon, 29 Jun 2009 11:38:11 +0200 (CEST) Message-ID: <4A488BE2.8060905@net.in.tum.de> Date: Mon, 29 Jun 2009 11:39:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20090629155310.3A56.17391CF2@nttv6.net> <4A4875D1.80006@net.in.tum.de> <20090629174637.3A64.17391CF2@nttv6.net> In-Reply-To: <20090629174637.3A64.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000806010605010807010702" X-Virus-Scanned: ClamAV using ClamSMTP Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:38:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000806010605010807010702 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Atsushi, Atsushi Kobayashi wrote: > Hi Gerhard and all, >=20 > Yes, it is more important that Original Exporter can host Intermediate > Process. >=20 > Your suggestion is fine for me. However, Intermediate Process definitio= n > already uses term "IPFIX Mediator" in previous paragraph. There is > little bit strange if just your proposal is put in it. Ah, you are right. > I would like to modify it as follows. >=20 > Intermediate Process >=20 > An Intermediate Process takes a sequence of records from a Collec= ting > Process, Metering Process, IPFIX File Reader, or another Intermed= iate > Process within a same device; performs some transformation on the= se records > ^^^^^^^^^^^^ > based upon the content of the records themselves, state kept acro= ss > multiple records, configuration parameters, or other data; and pa= sses > a sequence of transformed records on to an Exporting Process, IPF= IX File > Writer, or another Intermediate Process within a same device.=20 > ^^^^^^^^^^^^^ > Typically, an Intermediate Process is hosted by an IPFIX Mediator= =2E > Alternatively, an Intermediate Process may be hosted by an Origin= al > Exporter. What about removing those parts of the sentence: Intermediate Process An Intermediate Process takes a sequence of records from a Collecting Process, Metering Process, IPFIX File Reader, or another Intermediate Process; performs some transformation on these records based upon the content of the records themselves, state kept across multiple records, configuration parameters, or other data; and passes a sequence of transformed records on to an Exporting Process, IPFIX File Writer, or another Intermediate Proces. Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, an Intermediate Process may be hosted by an Original Exporter. Regards, Gerhard > Does it make sense? >=20 > Regards, > Atsushi >=20 > On Mon, 29 Jun 2009 10:05:37 +0200 > Gerhard Muenz wrote: >=20 >> Hi Atsushi, >> >> Atsushi Kobayashi wrote: >>> Hi Gerhard and all, >>> >>> The definition implies that the Original Exporter hosting IP is not >>> IPFIX Mediator. Because it mentions that the IPFIX Mediator receives >>> records from some data source. >> This is how I understood the terminology. >> My question was if this is intended. >> >>> To clarify, do we need to modify as follows? >>> >>> IPFIX Mediator >>> >>> An IPFIX Mediator is an IPFIX Device that provides mediation >>> capabilities by receiving records from some exporting device, h= osting >>> ^^^^^^^^^^^^^^^^^^^^^ >>> zero or more Intermediate Processes to transform those records,= >>> and exporting those records in IPFIX Messages via an Exporting >>> Process. In the common case, a Mediator receives records from = a >>> Collecting Process, but could also receive records from data >>> sources not encoded using IPFIX, e.g., in the case of NetFlow V= 9 >>> protocol translation. Specific types of Mediators are defined >>> below; some of these reference original mediation capabilities >>> defined in earlier IPFIX documens before the elaboration of the= >>> Mediator problem statement. >> No. >> >> If you want to clarify something, you could add a sentence to the IP >> definition, for example: >> >> Intermediate Process >> ... >> Typically, an Intermediate Process is hosted by an IPFIX Mediator. >> Alternatively, an Intermediate Process may be hosted by an Original >> Exporter. >> >> Gerhard >> >> >>> Regards, >>> Atsushi >>> >>> On Sat, 27 Jun 2009 15:53:19 +0200 >>> Gerhard Muenz wrote: >>> >>>> Hi Benoit, >>>> >>>> Thanks for the wrap up. I'm fine with this terminology. >>>> >>>> Just for clarification: >>>> An Original Exporter hosting an Intermediate Process is not an IPFIX= >>>> Mediator according to your definition, right? >>>> >>>> s/recieve/receive >>>> >>>> Regards, >>>> Gerhard >>>> >>>> >>>> Benoit Claise wrote: >>>>> Dear all, >>>>> >>>>> I'm trying to summarize the long email thread. Not easy, there are = some >>>>> diverging opinions. I hope I haven't forgotten anything >>>>> Below is the terminology proposal, based on Brian's proposal, impro= ved >>>>> by Gerhard, and everybody. >>>>> >>>>> 2. Terminology and Definitions >>>>> >>>>> The terms in this section are in line with those in the IPFIX >>>>> Protocol specifications [RFC5101] and the PSAMP specification >>>>> document [RFC5476]. The terms Observation Point, Observation Dom= ain, >>>>> Flow Key, Flow Record, Data Record, Exporting Process, Exporter, >>>>> IPFIX Device, Collecting Process, Collector, IPFIX Message, Meter= ing >>>>> Process, Transport Session, Information Element, and Template >>>>> Withdrawal Message, are defined in the IPFIX protocol specificati= ons >>>>> [RFC5101]. The terms Packet Report, Sampling, Filtering, PSAMP >>>>> Device, and Configured Selection Fraction are defined in the PSAM= P >>>>> specification document [RFC5476]. Furthermore, new terminology t= o be >>>>> used in the context of IPFIX Mediation is defined in this section= =2E >>>>> All these terms have an initial capital letter in this document. >>>>> >>>>> In this document, we use the generic term "Data Records" for IPFI= X >>>>> Flow Records, PSAMP Packet Reports, Data Records defined by Optio= ns >>>>> Templates, unless an explicit distinction is required. >>>>> >>>>> Original Exporter >>>>> >>>>> Original Exporter is an IPFIX Device that hosts the Observatio= n >>>>> Points where the metered IP packets are observed. >>>>> >>>>> IPFIX Mediation =20 >>>>> IPFIX Mediation describes the manipulation and conversion of r= ecords >>>>> for subsequent export using IPFIX, by applying mediation funct= ions >>>>> within one or more Intermediate Processes to a stream of recor= ds in >>>>> an IPFIX Mediator. >>>>> >>>>> The following terms are used in this document to describe the >>>>> architectural entities used by IPFIX Mediation. >>>>> >>>>> Intermediate Process >>>>> >>>>> An Intermediate Process takes a sequence of records from a Col= lecting >>>>> Process, Metering Process, IPFIX File Reader, or another Inter= mediate >>>>> Process within a Mediator; performs some transformation on the= se >>>>> records >>>>> based upon the content of the records themselves, state kept a= cross >>>>> multiple records, configuration parameters, or other data; and= passes >>>>> a sequence of transformed records on to an Exporting Process, = IPFIX >>>>> File >>>>> Writer, or another Intermediate Process within a Mediator. Thi= s >>>>> document >>>>> describes specific Intermediate Processes below used in the >>>>> elaboration >>>>> of the problem statement; however, this is not an exhaustive l= ist. >>>>> >>>>> Intermediate Aggregation Process >>>>> >>>>> An Intermediate Aggregation Process is an Intermediate Process = that >>>>> aggregates records based upon a set of Flow Keys, or functions >>>>> applied to fields from the record (e.g. binning, subnet aggrega= tion). >>>>> >>>>> Intermediate Correlation Process >>>>> >>>>> An Intermediate Correlation Process is an Intermediate Process= >>>>> which adds information to records noting correlations among th= em, >>>>> or generates new records with correlated data from multiple >>>>> records (e.g. the production of bidirectional flow records fro= m >>>>> unidirectional flow records). >>>>> >>>>> Intermediate Selection Process >>>>> >>>>> An Intermediate Selection Process is an Intermediate Process t= hat >>>>> selects records from a sequence based upon criteria evaluated >>>>> record values, and passes only those records that match the >>>>> criteria (e.g. filtering only records from a given network to = a >>>>> given Collector). >>>>> >>>>> Intermediate Anonymisation Process >>>>> >>>>> An Intermediate Anonymisation Process is an Intermediate Proce= ss >>>>> that transforms records in order to anonymise them, to protect= the >>>>> identity of the entities described by the records (e.g. by >>>>> applying prefix-preserving pseudonymisation of IP addresses). >>>>> >>>>> IPFIX Mediator >>>>> >>>>> An IPFIX Mediator is an IPFIX Device that provides mediation >>>>> capabilities by receiving records from some data source, hosti= ng >>>>> zero or more Intermediate Processes to transform those records= , >>>>> and exporting those records in IPFIX Messages via an Exporting= >>>>> Process. In the common case, a Mediator receives records from= a >>>>> Collecting Process, but could also receive records from data >>>>> sources not encoded using IPFIX, e.g., in the case of NetFlow = V9 >>>>> protocol translation. Specific types of Mediators are defined= >>>>> below; some of these reference original mediation capabilities= >>>>> defined in earlier IPFIX documens before the elaboration of th= e >>>>> Mediator problem statement. >>>>> >>>>> Original Exporter >>>>> >>>>> Original Exporter is an IPFIX Device that hosts the Observatio= n >>>>> Points where the metered IP packets are observed. >>>>> >>>>> IPFIX Proxy >>>>> >>>>> An IPFIX Proxy is an IPFIX Mediator that relays incoming IPFIX= >>>>> Messages or messages in other protocols to one or more Collect= ors. >>>>> It can provide transport protocol mediation and re-encoding. >>>>> >>>>> IPFIX Concentrator >>>>> >>>>> An IPFIX Concentrator is an IPFIX Mediator that recieves data = from >>>>> one or more Exporters and sends them to a single Collector, >>>>> optionally transforming the records using zero or more >>>>> Intermediate Processes on the way. >>>>> >>>>> IPFIX Distributor >>>>> >>>>> An IPFIX Distributor is an IPFIX Mediator that recieves data f= rom >>>>> one or more Exporters and sends them to one or more Collectors= , >>>>> deciding which Collector(s) to send each record to based upon = the >>>>> decision of an Intermediate Selection Process. >>>>> >>>>> IPFIX Masquerading Proxy >>>>> >>>>> An IPFIX Masquerading Proxy is an IPFIX Mediator that recieves= >>>>> data from one or more Exporters and sends them to a single >>>>> Collector, using one or more Intermediate Aggregation Function= s >>>>> and Intermediate Anonymisation Functions to screen out parts o= f >>>>> records according to configured policies, in order to protect = the >>>>> privacy of the network's end users or senstive data of the >>>>> exporting organization. >>>>> >>>>> >>>>> I think that we agree that the same terminology sections in both th= e >>>>> problem statement and framework. >>>>> Personally, I'm not sure (yet) if we need the Intermediate >>>>> Aggregation/Correlation/Selection/Anonynisation Process. >>>>> However, if we do, my proposal is to omit this list from the proble= m >>>>> statement, and to simply put them in the framework. >>>>> >>>>> Please let us know, so that we can move forward with the drafts, bo= th >>>>> the problem statements and the framework. >>>>> >>>>> Regards, Benoit. >=20 > ---=20 > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 >=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 --------------ms000806010605010807010702 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr 33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5 MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq 9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11 ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5 vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwNjI5MDkzOTQ2WjAjBgkqhkiG9w0BCQQxFgQU +8jPKX0nRGKr05RzrHdYkov4pFYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP MA0GCSqGSIb3DQEBAQUABIIBAGleAPpPOeGLxKwZoVBXC7EahzrGdOuUIjNZiNRvTFT9+PJB HGrhhwKisOX+tC+vdOlDooLGZ8B3vAjtL4f5//uZBIdrZP+Cb8VjifTTkcmrYlSoKh/SfjVX HfFnfTt1hHbmgssTjW+jBfA+s71fu8VLWrBxYAqGpwiuwvU5EN+1Ehpt9dWoFqCsNOyvVq8M CHXQf+KbHdqGftR6nVaoRl8Wuu/Hf5M7BJo4o0GrGS6y4OmvNiw+C37P6e2VPz2RlTUny4RJ 82af0BsLv9eG7I+PcosuuqFePMYyUTe/uT8pooI1smYMXnyHJPc4MVQNs2+tTrUfp3dEAYh/ S3Vo2FUAAAAAAAA= --------------ms000806010605010807010702-- From akoba@nttv6.net Mon Jun 29 02:45:25 2009 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C71828C1C4 for ; Mon, 29 Jun 2009 02:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 u9-PSyzQDO9H for ; Mon, 29 Jun 2009 02:45:25 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 6E21328C19E for ; Mon, 29 Jun 2009 02:45:24 -0700 (PDT) Received: from [192.47.163.152] ([IPv6:2001:fa8:1000:0:1c6b:3899:3a76:6a20]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id n5T9iaw8073090; Mon, 29 Jun 2009 18:44:36 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 29 Jun 2009 18:40:42 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4A488BE2.8060905@net.in.tum.de> References: <20090629174637.3A64.17391CF2@nttv6.net> <4A488BE2.8060905@net.in.tum.de> Message-Id: <20090629183914.3A6A.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 29 Jun 2009 18:44:36 +0900 (JST) Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-mediators-problem-statement-03 -> terminology, summary? X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:45:25 -0000 Hi Gerhard, and all, It's fine for me. Thanks. Atsushi On Mon, 29 Jun 2009 11:39:46 +0200 Gerhard Muenz wrote: > Intermediate Process > An Intermediate Process takes a sequence of records from a Collecting > Process, Metering Process, IPFIX File Reader, or another Intermediate > Process; performs some transformation on these records based upon the > content of the records themselves, state kept across multiple records, > configuration parameters, or other data; and passes a sequence of > transformed records on to an Exporting Process, IPFIX File Writer, or > another Intermediate Proces. > Typically, an Intermediate Process is hosted by an IPFIX Mediator. > Alternatively, an Intermediate Process may be hosted by an Original > Exporter. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637
Subject: Re: [Tsvwg] WG adoption of = draft-stewart-tsvwg-sctpstrrst
Date: Mon, 27 Apr 2009 16:28:41 -0400
From: Lars Eggert <lars.eggert@nokia.com>
To: tsvwg <tsvwg@ietf.org>
CC: draft-stewa= rt-tsvwg-sctpstrrst@tools.ietf.org
References: <EF897F= 3E-88F2-4917-B02C-9507ADB2081E@nokia.com>