From cjyoujsd@yahoo.com.cn Wed Nov 01 03:15:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfBG2-0008C9-W3 for PSAMP-ARCHIVE@MEGATRON.IETF.ORG; Wed, 01 Nov 2006 03:15:35 -0500 Received: from [218.8.172.147] (helo=a-net.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfBFy-0007dS-8w for PSAMP-ARCHIVE@MEGATRON.IETF.ORG; Wed, 01 Nov 2006 03:15:34 -0500 Received: from wbf7 (unknown [94.224.239.23]) by smtp86 (Coremail) with SMTP id dpSmCDFAoYn9kHMq.1 for ; Wed, 01 Nov 2006 16:15:29 +0800 (CST) X-Originating-IP: [94.224.239.23] Subject: =?iso-2022-jp?B?GyRCIUE0MEE0TDVOQUVQTz9AKSU1JSQlSCROJCpDTiRpJDshQRsoQg==?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C6C3C8.C1C77E30" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.0 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C6C3C8.C1C77E30 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCISEhITdQOlFFKiU1JV0hPCVIMkRHPSRKJVEhPCVIJUohPCRyJCpDNSQ3JEckOSQrISkbKEIN Cg0KGyRCJCo2YiRLJCo6JCRqJE5KfSRyJTUlXSE8JUgkNyQ/JCQhIhsoQlNFWBskQiVpJSQlVSRy NWEkYSRGJCQkayFERXkbKEINChskQjUuSn0kckksTVckSCQ3JEYkJCRrPXdALSRPJD8kLyQ1JHM1 byReJDkhKhsoQg0KDQoNChskQiIhNDBBNCRLTDVOQUVQTz9AKSF1NEpDMUVQTz8kLCRHJC0kRkIo QWo8akM1JDcyREc9ISobKEINChskQjRKQzFFUE8/JEdCKD1QMnEkJCIqGyhCaHR0cDovL3ZpZm4u Y29tLz9oYXJ1MjEyDQoNChskQiEhISEiKCMxIzg6UEwkS34kTkp9JE5FUE8/JE84RyQvJCpDRyRq JDckRiQkJF4kOSIoGyhCDQoNCg0KGyRCKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwo LCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwbKEINCg0KGyRCISFHWz8uSVRNVyRPJDMkQSRpS3giKiEh GyhCb2ZmaWNlX25ld3NfaGltaXRzdUB5YWhvby5jby5qcA0KDQpVc2VsZXNzbmVzcyB0byBzZXJ2 ZRskQiIqISEbKEJvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwDQo= ------=_NextPart_000_0006_01C6C3C8.C1C77E30 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj Ij48Rk9OVCANCnNpemU9Mj4bJEIhISEhN1A6UUUqJTUlXSE8JUgyREc9JEolUSE8JUglSiE8JHIk KkM1JDckRyQ5JCshKRsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgDQpzaXplPTI+GyRCJCo2YiRLJCo6JCRqJE5KfSRyJTUl XSE8JUgkNyQ/JCQhIhsoQlNFWBskQiVpJSQlVSRyNWEkYSRGJCQkayFERXkbKEI8QlI+GyRCNS5K fSRySSxNVyRIJDckRiQkJGs9d0AtJE8kPyQvJDUkczVvJF4kOSEqGyhCPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48QlI+PEZPTlQgDQpz aXplPTI+GyRCIiE0MEE0JEtMNU5BRVBPP0ApIXU0SkMxRVBPPyQsJEckLSRGQihBajxqQzUkNzJE Rz0hKhsoQjxCUj4bJEI0SkMxRVBPPyRHQig9UDJxJCQiKhsoQmh0dHA6Ly92aWZuLmNvbS8/aGFy dTIxMjwvRk9OVD48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4bJEIhISEhIigjMSM4OlBM JEt+JE5KfSRORVBPPyRPOEckLyQqQ0ckaiQ3JEYkJCReJDkiKBsoQjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPhskQigsKCwoLCgsKCwoLCgsKCwo LCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsKCwoLCgsGyhCPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPjxGT05UIHNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0y PjwvRk9OVD48Rk9OVCANCnNpemU9Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD48QlI+PEZP TlQgc2l6ZT0xPhskQiEhR1s/LklUTVckTyQzJEEkaUt4IiohIRsoQjwvRk9OVD48QSANCmhyZWY9 Im1haWx0bzpvZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwIj48Rk9OVCANCnNpemU9MT5v ZmZpY2VfbmV3c19oaW1pdHN1QHlhaG9vLmNvLmpwPC9GT05UPjwvQT48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0xPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0xPlVzZWxlc3Nu ZXNzIHRvIHNlcnZlGyRCIiohIRsoQjwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpvZmZpY2VfbmV3 c19oaW1pdHN1QHlhaG9vLmNvLmpwIj48Rk9OVCANCnNpemU9MT5vZmZpY2VfbmV3c19oaW1pdHN1 QHlhaG9vLmNvLmpwPC9GT05UPjwvQT48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C6C3C8.C1C77E30-- From psamp-bounces@ietf.org Mon Nov 06 18:42:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE5T-0004QN-Js; Mon, 06 Nov 2006 18:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhE5S-0004Pu-Ce for psamp@ietf.org; Mon, 06 Nov 2006 18:41:06 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhE5Q-0007EI-RX for psamp@ietf.org; Mon, 06 Nov 2006 18:41:06 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kA6NdMD25112; Tue, 7 Nov 2006 00:39:22 +0100 (MET) 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 Subject: RE: [PSAMP] Metering Process and/or Selection Process Date: Tue, 7 Nov 2006 00:40:51 +0100 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA1550D6F@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] Metering Process and/or Selection Process Thread-Index: Acbu5VHcUl1kdvNrRQKO9jbdaJcf/AS91/+Q From: "Zseby, Tanja" To: "Benoit Claise" , "psamp" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Hi Benoit, my understanding was that we now only define the IPFIX metering process and remove the PSAMP measurement process. As a result packets or flows can be exported. The IPFIX metering process can include a selection process (as defined in the IPFIX drafts). So I would agree with drawing 1. If there is the need to clarify those terms further, the best would be to have a short meeting at IETF this week. Regards, Tanja=20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com]=20 > Sent: Friday, October 13, 2006 6:32 PM > To: psamp > Subject: [PSAMP] Metering Process and/or Selection Process >=20 > Tanja, all, >=20 > I want to start a new email thread, discussing one of the=20 > point raised by Tanja in=20 > http://www1.ietf.org/mail-archive/web/psamp/current/msg00325.html >=20 >=20 > 2: Section 3.3.1: As far as I know we agreed that we=20 > use the same metering process definition for IPFIX and PSAMP.=20 > So the only difference I see between PSAMP and IPFIX=20 > processes are the Information elements that are reported. So=20 > I found section 3.3.1. a bit confusing.=20 > =09 >=20 > Note: in Dallas, we agreed to replace the "measurement=20 > process" by the "metering process" > While re-reading this section 3.3.1, I agree this is=20 > confusing. So we have to change this text/picture =20 >=20 > The figure B indicates the sequence of the processes=20 > (selection and=20 > exporting) within the PSAMP Device.=20 > =20 > +----------+ +-----------+=20 > Observed | Metering | | Exporting |=20 > Packet--->| Process |----->| Process |--->Collector=20 > Stream +----------+ +-----------+=20 > =20 > Figure B: PSAMP Processes=20 > =20 > The Selection Process, which takes an Observed Packet=20 > Stream as its=20 > input and produces Packet Reports as its output, is an=20 > integral part=20 > of the Metering Process, which by its definition produces Flow=20 > Records as its output.=20 >=20 >=20 > I was wondering how to change this: basically, we've got 2 choices! > Drawing 1: > =20 > +------------------+=20 > | Metering Process |=20 > | +-----------+ | +-----------+=20 > Observed | | Selection | | | Exporting |=20 > Packet--->| | Process |--------->| Process |--->Collector=20 > Stream | +-----------+ | +-----------+=20 > +------------------+ >=20 > This would be consistent with the text in section 3.3.1: >=20 >=20 > The Selection Process, which takes an Observed Packet=20 > Stream as its input and produces Packet Reports as its=20 > output, is an integral part of the Metering Process, which by=20 > its definition produces Flow Records as its output. > =09 > =09 >=20 > Drawing 2: >=20 > +-----------+ +----------+ +-----------+=20 > Observed | Selection | | Metering | | Exporting |=20 > Packet--->| Process |-->| Process |--->| Process |--->Collector=20 > Stream +-----------+ +----------+ +-----------+=20 > =20 > Figure B: PSAMP Processes >=20 > This would be consistent with the text in section 3.2.2:=20 >=20 > Selection Process=20 > =20 > A Selection Process takes the Observed Packet Stream as=20 > its input and=20 > selects a subset of that stream as its output.=20 >=20 >=20 >=20 >=20 > However, we quickly realize that we've an inconsistency in=20 > the following definitions; >=20 >=20 > Selection Process=20 > =20 > A Selection Process takes the Observed Packet Stream as=20 > its input and=20 > selects a subset of that stream as its output.=20 > Report Stream=20 > =20 > The Report Stream is the output of a Selection Process, comprising=20 > two distinguished types of information: Packet Reports, and Report=20 > Interpretation. >=20 > One definition says that the selection process doesn't=20 > generate the report stream while another says the reverse. > To solve this issue we've got 2 solutions: >=20 >=20 > Solution 1: > We divide the metering process into a Selection Process=20 > (Packet Stream in, Selected Packets out) and a Reporting=20 > Process (Selected Packets In, Packet Reports Out). This is=20 > the way it's done in [PSAMP-FRAMEWORK]: >=20 > * Report Stream:=20 > =20 > The report stream is the output of a reporting process,=20 > comprising two distinguished types of information: packet=20 > reports, and report interpretation.=20 > As far as I recall, we decided to remove the Reporting=20 > Process from [PSAMP-PROTO]... This rules out solution 1. >=20 > Solution 2: >=20 > +-----------+ +----------+ +-----------+=20 > Observed | Selection | | Metering | | Exporting |=20 > Packet--->| Process |-->| Process |--->| Process |--->Collector=20 > Stream +-----------+ +----------+ +-----------+=20 > =20 > Figure B: PSAMP Processes >=20 > So it means that PSAMP =3D IPFIX + an extra Selection Process. > We must update=20 >=20 > Report Stream=20 > =20 > The Report Stream is the output of a Metering (AND NOT=20 > SELECTION) Process,=20 > comprising two distinguished types of information: Packet=20 > Reports, and Report=20 > Interpretation >=20 > Solution 3:=20 >=20 > =20 > +------------------+=20 > | Metering Process |=20 > | +-----------+ | +-----------+=20 > Observed | | Selection | | | Exporting |=20 > Packet--->| | Process |--------->| Process |--->Collector=20 > Stream | +-----------+ | +-----------+=20 > +------------------+ >=20 > So the metering process: Packet Stream in, Packet Reports out. > We must update=20 >=20 > Report Stream=20 > =20 > The Report Stream is the output of a Metering (AND NOT=20 > SELECTION) Process,=20 > comprising two distinguished types of information: Packet=20 > Reports, and Report=20 > Interpretation >=20 > What's your preferred solution? >=20 > Regards, Benoit.=20 >=20 >=20 >=20 > =20 >=20 >=20 >=20 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Thu Nov 09 21:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMPi-0001PI-W2; Thu, 09 Nov 2006 21:46:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiMPh-0001P9-0B for psamp@ietf.org; Thu, 09 Nov 2006 21:46:41 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiMPf-0008NW-BC for psamp@ietf.org; Thu, 09 Nov 2006 21:46:40 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CEB8920031E5 for ; Fri, 10 Nov 2006 03:47:07 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGJ-fXhV6RBx for ; Fri, 10 Nov 2006 03:47:07 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BAC4820031DA for ; Fri, 10 Nov 2006 03:47:07 +0100 (CET) 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: Fri, 10 Nov 2006 03:46:36 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: completing the PSAMP protocol Thread-Index: AccEcnCvpIIBGJGLSjGD/17YkOJtig== From: "Juergen Quittek" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [PSAMP] completing the PSAMP protocol X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Dear all, I am very happy that the IPFIX protocol has passed IESG evaluation and = will enter the RFC editor queue. Now we can have the PSAMP protocol = following=20 quickly. I think that draft-ietf-psamp-protocol-07.txt is in very good shape. There is only one issue I would like to discuss before submitting it to our AD with a request for publication. Please send a message to this list if yo see further issues. The issue is distinguishing PSAMP and IPFIX reports. An IPFIX flow report contains information about one or more packets while a PSAMP report contains information about exactly one packet. There is no problem with this if the report contains a packet counter. But if not, it might be unclear if, for example, an octet counter=20 indicates the number of octets of a flow or the number of octets of a single packet. Therefore, I would like to have a means to distinguish packet reports from flow reports. Does anyone have a good suggestion for solving this problem? Or does anyone think that is not a problem? Input is highly appreciated, because it will help completing the PSAMP protocol soon. Thanks, Juergen _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Fri Nov 10 03:47:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiS2S-0001vi-5K; Fri, 10 Nov 2006 03:47:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiS2Q-0001vc-Cy for psamp@ietf.org; Fri, 10 Nov 2006 03:47:02 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiS2N-0008Rk-G4 for psamp@ietf.org; Fri, 10 Nov 2006 03:47:02 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id A539F115 for ; Fri, 10 Nov 2006 09:46:57 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 33982-03 for ; Fri, 10 Nov 2006 09:46:55 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E3E5D141 for ; Fri, 10 Nov 2006 09:46:53 +0100 (NFT) Message-ID: <45543CB4.1080208@informatik.uni-tuebingen.de> Date: Fri, 10 Nov 2006 09:47:48 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: psamp@ietf.org Subject: Re: [PSAMP] completing the PSAMP protocol References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> X-Enigmail-Version: 0.94.0.0 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1871784477==" Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1871784477== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030203090006020904070903" This is a cryptographically signed message in MIME format. --------------ms030203090006020904070903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Juergen, I would say it is not a problem since a flow template/record usually contains a packet counter. However, we could recommend to export the packet counter within flow records if PSAMP and IPFIX data are exported by the same Exporter (or from the same Observation Domain). A related question is if it is allowed having packet counter and payload in the same record. If yes, how do you interprete the payload? Is it the payload of the first packet in the flow? Or is this issue already clarified in the PSAMP specifications? Regards, Gerhard Juergen Quittek wrote: > Dear all, >=20 > I am very happy that the IPFIX protocol has passed IESG evaluation and = will > enter the RFC editor queue. Now we can have the PSAMP protocol followi= ng=20 > quickly. >=20 > I think that draft-ietf-psamp-protocol-07.txt is in very good shape. > There is only one issue I would like to discuss before submitting it > to our AD with a request for publication. Please send a message to > this list if yo see further issues. >=20 > The issue is distinguishing PSAMP and IPFIX reports. >=20 > An IPFIX flow report contains information about one or more packets > while a PSAMP report contains information about exactly one packet. > There is no problem with this if the report contains a packet counter. > But if not, it might be unclear if, for example, an octet counter=20 > indicates the number of octets of a flow or the number of octets of > a single packet. Therefore, I would like to have a means to distinguis= h > packet reports from flow reports. >=20 > Does anyone have a good suggestion for solving this problem? >=20 > Or does anyone think that is not a problem? >=20 > Input is highly appreciated, because it will help completing > the PSAMP protocol soon. >=20 > Thanks, >=20 > Juergen >=20 >=20 > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030203090006020904070903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MTExMDA4NDc0OFowIwYJKoZIhvcNAQkEMRYEFGKFi0hBi20P UObtwAh0SDlM4GgnMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQDZu0Zh6QnrIdBOLN4Kp3MxtiNzAoTXr570Q1TogtHnxnlEVvyQAl03Rg1B KyCy5Tcu6Fvntle+2e+/nDZLpbErQZJj1GHwQFV1dKZwjiJXX0OL4QUr7M1Z1A6YESS3ZYPH gXGh3BUv7dDWNpVIJ38lH9IvEjC63NpliqnJU0gwuybFQlxOlZUVsHmXQo9pf9+L3X02+/QV B5NyW++iDmbBTp1s9/T/RKnkNuqPb8Z4/ZDTyZViCvFmugvSP8hT0QlyW6lKKNqcOo77P0YJ FvGw6BX+Ea3mya/YbD9OHbpBVlTM2K3JU534MsriEO0xBIHjmyB6Z65XqBCh7cJw4+F0AAAA AAAA --------------ms030203090006020904070903-- --===============1871784477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============1871784477==-- From psamp-bounces@ietf.org Fri Nov 10 04:24:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiScM-00047V-4E; Fri, 10 Nov 2006 04:24:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiScK-00047Q-0X for psamp@ietf.org; Fri, 10 Nov 2006 04:24:08 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiScI-0002c3-H2 for psamp@ietf.org; Fri, 10 Nov 2006 04:24:07 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2FD8820031EF; Fri, 10 Nov 2006 10:24:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWmvQzREjXgW; Fri, 10 Nov 2006 10:24:36 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 188DD20031DA; Fri, 10 Nov 2006 10:24:36 +0100 (CET) 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 Subject: Re: [PSAMP] completing the PSAMP protocol Date: Fri, 10 Nov 2006 10:24:05 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBE@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PSAMP] completing the PSAMP protocol Thread-Index: AccEqfeO7aCF4AqnSyWLhCqH8evS0A== From: "Juergen Quittek" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Hi Gerhard, --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: > > Dear Juergen, > > I would say it is not a problem since a flow template/record usually > contains a packet counter. Yes, most time it is not a problem. But I am concerned about the cases where you do not have a packet = counter or another clear indicator in the report. But even if you have an = indicator that tells a human observer "This looks like a flow record", I do not = want to implement all the required intelligence into a collector in order to have him distinguish between flow record and packet record by smart = reflections on the IEs in the record. A simple and clear indicator should not be = costly and avoid any confusion. > However, we could recommend to export the packet counter within flow > records if PSAMP and IPFIX data are exported by the same Exporter (or > from the same Observation Domain). What about sending a packet counter with value 1 in an option template for packet reports? > A related question is if it is allowed having packet counter and = payload > in the same record. If yes, how do you interprete the payload? Is it = the > payload of the first packet in the flow? Yes. > Or is this issue already clarified in the PSAMP specifications? No. This is already addressed by the IPFIX info model document. > Regards, > Gerhard > > Juergen Quittek wrote: >> Dear all, >> >> I am very happy that the IPFIX protocol has passed IESG evaluation = and will >> enter the RFC editor queue. Now we can have the PSAMP protocol = following >> quickly. >> >> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >> There is only one issue I would like to discuss before submitting it >> to our AD with a request for publication. Please send a message to >> this list if yo see further issues. >> >> The issue is distinguishing PSAMP and IPFIX reports. >> >> An IPFIX flow report contains information about one or more packets >> while a PSAMP report contains information about exactly one packet. >> There is no problem with this if the report contains a packet = counter. >> But if not, it might be unclear if, for example, an octet counter >> indicates the number of octets of a flow or the number of octets of >> a single packet. Therefore, I would like to have a means to = distinguish >> packet reports from flow reports. >> >> Does anyone have a good suggestion for solving this problem? >> >> Or does anyone think that is not a problem? >> >> Input is highly appreciated, because it will help completing >> the PSAMP protocol soon. >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp > > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz =20 _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Sat Nov 11 09:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gitav-0002my-5G; Sat, 11 Nov 2006 09:12:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gitat-0002mt-V7 for psamp@ietf.org; Sat, 11 Nov 2006 09:12:27 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gitao-0007om-FK for psamp@ietf.org; Sat, 11 Nov 2006 09:12:27 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 79DAE13CF82; Sat, 11 Nov 2006 15:14:58 +0100 (CET) Date: Sat, 11 Nov 2006 11:40:17 +0100 From: Juergen Quittek To: Gerhard Muenz , psamp@ietf.org Subject: Re: [PSAMP] completing the PSAMP protocol Message-ID: <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> In-Reply-To: <45543CB4.1080208@informatik.uni-tuebingen.de> References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Gerhard, Let me add further clarification. I am not necessarily requesting that a single flow record contains means for distinguishing between a flow record and a packet record. Such information could also be communicated in the template or in an option record. However, there is a semantic difference between a packet record and a flow record. Even if a packet record and a flow record are identical for every bit they contain, the contained information is different. Therefore, I want a collector to be able to distinguish between them. This is certainly not a problem for records containing a packet counter. But IPFIX allows flow records that do not have packet counters. In such a case the collector needs further information about the received data. Since IPFIX is the base protocol, I would see a flow record as the default case that does not need any specific tag. But for packet records I would like to see a means that clearly identifies them as such. Thanks, Juergen --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: > > Dear Juergen, > > I would say it is not a problem since a flow template/record usually > contains a packet counter. > > However, we could recommend to export the packet counter within flow > records if PSAMP and IPFIX data are exported by the same Exporter (or > from the same Observation Domain). > > A related question is if it is allowed having packet counter and payload > in the same record. If yes, how do you interprete the payload? Is it the > payload of the first packet in the flow? > Or is this issue already clarified in the PSAMP specifications? > > Regards, > Gerhard > > Juergen Quittek wrote: >> Dear all, >> >> I am very happy that the IPFIX protocol has passed IESG evaluation and will >> enter the RFC editor queue. Now we can have the PSAMP protocol following >> quickly. >> >> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >> There is only one issue I would like to discuss before submitting it >> to our AD with a request for publication. Please send a message to >> this list if yo see further issues. >> >> The issue is distinguishing PSAMP and IPFIX reports. >> >> An IPFIX flow report contains information about one or more packets >> while a PSAMP report contains information about exactly one packet. >> There is no problem with this if the report contains a packet counter. >> But if not, it might be unclear if, for example, an octet counter >> indicates the number of octets of a flow or the number of octets of >> a single packet. Therefore, I would like to have a means to distinguish >> packet reports from flow reports. >> >> Does anyone have a good suggestion for solving this problem? >> >> Or does anyone think that is not a problem? >> >> Input is highly appreciated, because it will help completing >> the PSAMP protocol soon. >> >> Thanks, >> >> Juergen >> >> >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp > > -- > Dipl.-Ing. Gerhard M=C3=BCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Sand 13 (Room B309), D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > E-mail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Sun Nov 12 05:36:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjCg4-0000Kh-Ge; Sun, 12 Nov 2006 05:35:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjCg3-0000KW-5I for psamp@ietf.org; Sun, 12 Nov 2006 05:35:03 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjCg1-0008A3-8z for psamp@ietf.org; Sun, 12 Nov 2006 05:35:03 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id DAB15122; Sun, 12 Nov 2006 11:34:49 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33796-02; Sun, 12 Nov 2006 11:34:47 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id EEC9B11C; Sun, 12 Nov 2006 11:34:44 +0100 (MET) Message-ID: <4556F8EE.1020504@informatik.uni-tuebingen.de> Date: Sun, 12 Nov 2006 11:35:26 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [PSAMP] completing the PSAMP protocol References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> In-Reply-To: <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> X-Enigmail-Version: 0.94.0.0 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881301524==" Errors-To: psamp-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0881301524== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020102040903010404080602" This is a cryptographically signed message in MIME format. --------------ms020102040903010404080602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Juergen, Let me first comment the suggestion in your previous mail: > What about sending a packet counter with value 1 in an option template > for packet reports? The problem remains and becomes even worse if you use a flow counter for packet records: If the value is 1, it still might be a normal flow record= . The only solution would be to recommend the following: * always use flow counters for flow records, and * never use flow counters for packet records. If you want a stricter distinction between flow records and packet records, you might like this idea: We had a similar problem when specifying how to export records of filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved this by using a new template set (Data Template) which is announced with Set ID=3D4. This could also be a solution to distinguish between flow records and packet records: Use another Set ID (e.g. 5) to define a PSAMP Template Set. The format of the set would be the same as for normal (flow) Template Sets (Set ID=3D2), but the collector would know that the data originates from a PSAMP probe. Regards, Gerhard Juergen Quittek wrote: > Gerhard, >=20 > Let me add further clarification. >=20 > I am not necessarily requesting that a single > flow record contains means for distinguishing > between a flow record and a packet record. > Such information could also be communicated > in the template or in an option record. >=20 > However, there is a semantic difference between > a packet record and a flow record. Even if a packet > record and a flow record are identical for every bit > they contain, the contained information is different. > Therefore, I want a collector to be able to > distinguish between them. >=20 > This is certainly not a problem for records > containing a packet counter. But IPFIX allows flow > records that do not have packet counters. In such > a case the collector needs further information > about the received data. >=20 > Since IPFIX is the base protocol, I would see a flow > record as the default case that does not need any > specific tag. But for packet records I would like > to see a means that clearly identifies them as such. >=20 > Thanks, >=20 > Juergen >=20 >=20 > --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >=20 >> >> Dear Juergen, >> >> I would say it is not a problem since a flow template/record usually >> contains a packet counter. >> >> However, we could recommend to export the packet counter within flow >> records if PSAMP and IPFIX data are exported by the same Exporter (or >> from the same Observation Domain). >> >> A related question is if it is allowed having packet counter and paylo= ad >> in the same record. If yes, how do you interprete the payload? Is it t= he >> payload of the first packet in the flow? >> Or is this issue already clarified in the PSAMP specifications? >> >> Regards, >> Gerhard >> >> Juergen Quittek wrote: >>> Dear all, >>> >>> I am very happy that the IPFIX protocol has passed IESG evaluation >>> and will >>> enter the RFC editor queue. Now we can have the PSAMP protocol >>> following >>> quickly. >>> >>> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >>> There is only one issue I would like to discuss before submitting it >>> to our AD with a request for publication. Please send a message to >>> this list if yo see further issues. >>> >>> The issue is distinguishing PSAMP and IPFIX reports. >>> >>> An IPFIX flow report contains information about one or more packets >>> while a PSAMP report contains information about exactly one packet. >>> There is no problem with this if the report contains a packet counter= . >>> But if not, it might be unclear if, for example, an octet counter >>> indicates the number of octets of a flow or the number of octets of >>> a single packet. Therefore, I would like to have a means to distingu= ish >>> packet reports from flow reports. >>> >>> Does anyone have a good suggestion for solving this problem? >>> >>> Or does anyone think that is not a problem? >>> >>> Input is highly appreciated, because it will help completing >>> the PSAMP protocol soon. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp >> >> --=20 >> Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Sand 13 (Room B309), D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >> E-mail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> >=20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms020102040903010404080602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MTExMjEwMzUyNlowIwYJKoZIhvcNAQkEMRYEFFdJQ4+rX90O biT2X9pSoVghkqW/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQBpmxqKTuppz8sS9xyX7kRflcksb/mxfpfOKKi8IRweQFyqVnsA847k2zwu M6HPWcf5QaA7jtZgYW00q/4ITK++t3XgKCATYkmTFPpasmDLZdE78eXJsnbPjuXeZOmHChMV ZbG4Gt5yl8lRulC4BjDokYfmcrMCyyczrqKWf0JN/y0xufJj6uQnIXK8W9QRPoHbhvHg2muw R+Fk1L7Sj8a7VyU66uGYaPjEvB1e0hAVLJTr73K/IVtKrVtdZPUXeLHXs5t8C5WtSa4948bl uNJQfV6BuXG93PbvmFfF0sHGRHamQedPIHBPapAoOtmnC4YRhba8k9J47mmrJJSLTOrIAAAA AAAA --------------ms020102040903010404080602-- --===============0881301524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp --===============0881301524==-- From psamp-bounces@ietf.org Mon Nov 13 00:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjU4u-0003dq-TO; Mon, 13 Nov 2006 00:09:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjU4t-0003cr-8F for psamp@ietf.org; Mon, 13 Nov 2006 00:09:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjU4q-0004p3-J4 for psamp@ietf.org; Mon, 13 Nov 2006 00:09:51 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2006 06:09:48 +0100 X-IronPort-AV: i="4.09,415,1157320800"; d="scan'208"; a="119607339:sNHT61087952" 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 kAD59lP8000597; Mon, 13 Nov 2006 06:09:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAD59l4Z026434; Mon, 13 Nov 2006 06:09:47 +0100 (MET) Received: from [10.61.80.39] (ams3-vpn-dhcp4136.cisco.com [10.61.80.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id FAA25013; Mon, 13 Nov 2006 05:09:46 GMT Message-ID: <4557FDFB.1060906@cisco.com> Date: Mon, 13 Nov 2006 05:09:15 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Gerhard Muenz Subject: Re: [PSAMP] completing the PSAMP protocol References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> <4556F8EE.1020504@informatik.uni-tuebingen.de> In-Reply-To: <4556F8EE.1020504@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6011; t=1163394587; x=1164258587; 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=20[PSAMP]=20completing=20the=20PSAMP=20protocol |Sender:=20; bh=thieQrfC4Gxamy0Ij5YtdR3ORve1h0kmv/6gbHYqEYs=; b=aRXvFh1Vslec0ymmghh8od1+YtwYr+sEZ1LcEab8lW0JfPjWvD+KS+6Gbc7YvWZXBMEu1dTA mTj4ImWKItS26Xq4fXswjbK4q9bkHAFBcV039kxjn0+4ZHy0CKAhF7k0; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Hi all I'm not convinced that the application is needed in-band. IPFIX is a transportation protocol, the application using it should know what it's doing. OTOH, general purpose collectors seems a reasonable idea. So if an in-band way of knowing the application is desirable, then I don't think using packet counters is explicit enough and new Set IDs are going way too far. At that point PSAMP won't even be using IPFIX as defined in IPFIX PROTO. Why can't we just define a new application I.E.? I agree that the default application is going to be Flow Export, but IPFIX will have a number of application relatively soon. With a new I.E. we can send it per data record or in an option scoped to the template. It requires no protocol changes, is explicit and can be used flexibly. regards Andrew Gerhard Muenz wrote: > Juergen, > > Let me first comment the suggestion in your previous mail: > >> What about sending a packet counter with value 1 in an option template >> for packet reports? > > The problem remains and becomes even worse if you use a flow counter for > packet records: If the value is 1, it still might be a normal flow record. > > The only solution would be to recommend the following: > * always use flow counters for flow records, and > * never use flow counters for packet records. > > If you want a stricter distinction between flow records and packet > records, you might like this idea: > We had a similar problem when specifying how to export records of > filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved > this by using a new template set (Data Template) which is announced with > Set ID=4. > This could also be a solution to distinguish between flow records and > packet records: Use another Set ID (e.g. 5) to define a PSAMP Template > Set. The format of the set would be the same as for normal (flow) > Template Sets (Set ID=2), but the collector would know that the data > originates from a PSAMP probe. > > Regards, > Gerhard > > > Juergen Quittek wrote: >> Gerhard, >> >> Let me add further clarification. >> >> I am not necessarily requesting that a single >> flow record contains means for distinguishing >> between a flow record and a packet record. >> Such information could also be communicated >> in the template or in an option record. >> >> However, there is a semantic difference between >> a packet record and a flow record. Even if a packet >> record and a flow record are identical for every bit >> they contain, the contained information is different. >> Therefore, I want a collector to be able to >> distinguish between them. >> >> This is certainly not a problem for records >> containing a packet counter. But IPFIX allows flow >> records that do not have packet counters. In such >> a case the collector needs further information >> about the received data. >> >> Since IPFIX is the base protocol, I would see a flow >> record as the default case that does not need any >> specific tag. But for packet records I would like >> to see a means that clearly identifies them as such. >> >> Thanks, >> >> Juergen >> >> >> --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >> >>> Dear Juergen, >>> >>> I would say it is not a problem since a flow template/record usually >>> contains a packet counter. >>> >>> However, we could recommend to export the packet counter within flow >>> records if PSAMP and IPFIX data are exported by the same Exporter (or >>> from the same Observation Domain). >>> >>> A related question is if it is allowed having packet counter and payload >>> in the same record. If yes, how do you interprete the payload? Is it the >>> payload of the first packet in the flow? >>> Or is this issue already clarified in the PSAMP specifications? >>> >>> Regards, >>> Gerhard >>> >>> Juergen Quittek wrote: >>>> Dear all, >>>> >>>> I am very happy that the IPFIX protocol has passed IESG evaluation >>>> and will >>>> enter the RFC editor queue. Now we can have the PSAMP protocol >>>> following >>>> quickly. >>>> >>>> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >>>> There is only one issue I would like to discuss before submitting it >>>> to our AD with a request for publication. Please send a message to >>>> this list if yo see further issues. >>>> >>>> The issue is distinguishing PSAMP and IPFIX reports. >>>> >>>> An IPFIX flow report contains information about one or more packets >>>> while a PSAMP report contains information about exactly one packet. >>>> There is no problem with this if the report contains a packet counter. >>>> But if not, it might be unclear if, for example, an octet counter >>>> indicates the number of octets of a flow or the number of octets of >>>> a single packet. Therefore, I would like to have a means to distinguish >>>> packet reports from flow reports. >>>> >>>> Does anyone have a good suggestion for solving this problem? >>>> >>>> Or does anyone think that is not a problem? >>>> >>>> Input is highly appreciated, because it will help completing >>>> the PSAMP protocol soon. >>>> >>>> Thanks, >>>> >>>> Juergen >>>> >>>> >>>> _______________________________________________ >>>> PSAMP mailing list >>>> PSAMP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/psamp >>> -- >>> Dipl.-Ing. Gerhard Münz >>> Computer Networks and Internet >>> Wilhelm Schickard Institute for Computer Science >>> University of Tuebingen >>> Sand 13 (Room B309), D-72076 Tuebingen, Germany >>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>> E-mail: muenz@informatik.uni-tuebingen.de >>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >>> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Nov 13 11:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjetY-0003AO-Nb; Mon, 13 Nov 2006 11:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjetY-0003AJ-0Z for psamp@ietf.org; Mon, 13 Nov 2006 11:42:52 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjetV-00046U-93 for psamp@ietf.org; Mon, 13 Nov 2006 11:42:51 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 48C1B13CF82; Mon, 13 Nov 2006 17:45:33 +0100 (CET) Date: Mon, 13 Nov 2006 17:42:49 +0100 From: Juergen Quittek To: Andrew Johnson , Gerhard Muenz Subject: Re: [PSAMP] completing the PSAMP protocol Message-ID: In-Reply-To: <4557FDFB.1060906@cisco.com> References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> <4556F8EE.1020504@informatik.uni-tuebingen.de> <4557FDFB.1060906@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Hi all, --On 13.11.06 05:09 +0000 Andrew Johnson wrote: > Hi all > > I'm not convinced that the application is needed in-band. IPFIX is > a transportation protocol, the application using it should know what > it's doing. To be precise, it's an IP flow information export protocol :-) Here, we are using it for packet information export. > OTOH, general purpose collectors seems a reasonable idea. So if an > in-band way of knowing the application is desirable, then I don't > think using packet counters is explicit enough and new Set IDs are > going way too far. At that point PSAMP won't even be using IPFIX > as defined in IPFIX PROTO. The point is that it does not cost us much now to avoid confusion. I do not feel well with opening the possibility that two identical streams of reports have different meanings without the collector being able to distinguish. This does not imply that we need to change the protocol. We may, but IPFIX is rich enough to offer us several ways of giving the collector additional information on the records. > Why can't we just define a new application I.E.? I agree that the > default application is going to be Flow Export, but IPFIX will have > a number of application relatively soon. With a new I.E. we can > send it per data record or in an option scoped to the template. It > requires no protocol changes, is explicit and can be used flexibly. This would be a way to do it. Wouldn't you still call this in-band? Thanks, Juergen > regards > > Andrew > > > > Gerhard Muenz wrote: >> Juergen, >> >> Let me first comment the suggestion in your previous mail: >> >>> What about sending a packet counter with value 1 in an option template >>> for packet reports? >> >> The problem remains and becomes even worse if you use a flow counter for >> packet records: If the value is 1, it still might be a normal flow record. >> >> The only solution would be to recommend the following: >> * always use flow counters for flow records, and >> * never use flow counters for packet records. >> >> If you want a stricter distinction between flow records and packet >> records, you might like this idea: >> We had a similar problem when specifying how to export records of >> filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved >> this by using a new template set (Data Template) which is announced with >> Set ID=3D4. >> This could also be a solution to distinguish between flow records and >> packet records: Use another Set ID (e.g. 5) to define a PSAMP Template >> Set. The format of the set would be the same as for normal (flow) >> Template Sets (Set ID=3D2), but the collector would know that the data >> originates from a PSAMP probe. >> >> Regards, >> Gerhard >> >> >> Juergen Quittek wrote: >>> Gerhard, >>> >>> Let me add further clarification. >>> >>> I am not necessarily requesting that a single >>> flow record contains means for distinguishing >>> between a flow record and a packet record. >>> Such information could also be communicated >>> in the template or in an option record. >>> >>> However, there is a semantic difference between >>> a packet record and a flow record. Even if a packet >>> record and a flow record are identical for every bit >>> they contain, the contained information is different. >>> Therefore, I want a collector to be able to >>> distinguish between them. >>> >>> This is certainly not a problem for records >>> containing a packet counter. But IPFIX allows flow >>> records that do not have packet counters. In such >>> a case the collector needs further information >>> about the received data. >>> >>> Since IPFIX is the base protocol, I would see a flow >>> record as the default case that does not need any >>> specific tag. But for packet records I would like >>> to see a means that clearly identifies them as such. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >>> >>>> Dear Juergen, >>>> >>>> I would say it is not a problem since a flow template/record usually >>>> contains a packet counter. >>>> >>>> However, we could recommend to export the packet counter within flow >>>> records if PSAMP and IPFIX data are exported by the same Exporter (or >>>> from the same Observation Domain). >>>> >>>> A related question is if it is allowed having packet counter and payload >>>> in the same record. If yes, how do you interprete the payload? Is it the >>>> payload of the first packet in the flow? >>>> Or is this issue already clarified in the PSAMP specifications? >>>> >>>> Regards, >>>> Gerhard >>>> >>>> Juergen Quittek wrote: >>>>> Dear all, >>>>> >>>>> I am very happy that the IPFIX protocol has passed IESG evaluation >>>>> and will >>>>> enter the RFC editor queue. Now we can have the PSAMP protocol >>>>> following >>>>> quickly. >>>>> >>>>> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >>>>> There is only one issue I would like to discuss before submitting it >>>>> to our AD with a request for publication. Please send a message to >>>>> this list if yo see further issues. >>>>> >>>>> The issue is distinguishing PSAMP and IPFIX reports. >>>>> >>>>> An IPFIX flow report contains information about one or more packets >>>>> while a PSAMP report contains information about exactly one packet. >>>>> There is no problem with this if the report contains a packet counter. >>>>> But if not, it might be unclear if, for example, an octet counter >>>>> indicates the number of octets of a flow or the number of octets of >>>>> a single packet. Therefore, I would like to have a means to distinguish >>>>> packet reports from flow reports. >>>>> >>>>> Does anyone have a good suggestion for solving this problem? >>>>> >>>>> Or does anyone think that is not a problem? >>>>> >>>>> Input is highly appreciated, because it will help completing >>>>> the PSAMP protocol soon. >>>>> >>>>> Thanks, >>>>> >>>>> Juergen >>>>> >>>>> >>>>> _______________________________________________ >>>>> PSAMP mailing list >>>>> PSAMP@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/psamp >>>> -- >>>> Dipl.-Ing. Gerhard M=C3=BCnz >>>> Computer Networks and Internet >>>> Wilhelm Schickard Institute for Computer Science >>>> University of Tuebingen >>>> Sand 13 (Room B309), D-72076 Tuebingen, Germany >>>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>>> E-mail: muenz@informatik.uni-tuebingen.de >>>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >>>> >>> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Mon Nov 13 11:55:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf4c-0002u2-Lp; Mon, 13 Nov 2006 11:54:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjf4b-0002rJ-BI for psamp@ietf.org; Mon, 13 Nov 2006 11:54:17 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjf4Y-0005vn-Sb for psamp@ietf.org; Mon, 13 Nov 2006 11:54:17 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kADGrx3n031969 for ; Mon, 13 Nov 2006 11:54:08 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kADGqxZq031872 for ; Mon, 13 Nov 2006 11:52:59 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kADGqx1x031870; Mon, 13 Nov 2006 11:52:59 -0500 (EST) Received: from [128.237.225.216] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kADGqxg5012056; Mon, 13 Nov 2006 11:52:59 -0500 In-Reply-To: <4557FDFB.1060906@cisco.com> References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> <4556F8EE.1020504@informatik.uni-tuebingen.de> <4557FDFB.1060906@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0C7E50B9-68D1-4649-90D8-70A07208F69D@cert.org> Content-Transfer-Encoding: quoted-printable From: Brian Trammell Subject: Re: [PSAMP] completing the PSAMP protocol Date: Mon, 13 Nov 2006 11:52:21 -0500 To: Andrew Johnson X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Andrew, I agree fully... the use of such an information element shouldn't be =20 _required_, because in the general case I would suspect that the =20 application is implicit in the identity and configuration of the =20 Collecting and Exporting Processes. For our own applications, we've generally used the presence of =20 certain IEs (packet count for flows, flow count for aggregates) to =20 define the application as mentioned elsewhere in this thread. =20 However, in those cases in which it isn't possible to divine the =20 application from out-of-band configuration or the template, it's =20 quite useful to be able to represent the record type in-band. (Note also, this is very much parallel to the problem of representing =20= direction selection method for biflows.) Regards, Brian On Nov 13, 2006, at 12:09 AM, Andrew Johnson wrote: > Hi all > > I'm not convinced that the application is needed in-band. IPFIX is > a transportation protocol, the application using it should know what > it's doing. > > OTOH, general purpose collectors seems a reasonable idea. So if an > in-band way of knowing the application is desirable, then I don't > think using packet counters is explicit enough and new Set IDs are > going way too far. At that point PSAMP won't even be using IPFIX > as defined in IPFIX PROTO. > > Why can't we just define a new application I.E.? I agree that the > default application is going to be Flow Export, but IPFIX will have > a number of application relatively soon. With a new I.E. we can > send it per data record or in an option scoped to the template. It > requires no protocol changes, is explicit and can be used flexibly. > > regards > > Andrew > > > > Gerhard Muenz wrote: >> Juergen, >> Let me first comment the suggestion in your previous mail: >>> What about sending a packet counter with value 1 in an option =20 >>> template >>> for packet reports? >> The problem remains and becomes even worse if you use a flow =20 >> counter for >> packet records: If the value is 1, it still might be a normal flow =20= >> record. >> The only solution would be to recommend the following: >> * always use flow counters for flow records, and >> * never use flow counters for packet records. >> If you want a stricter distinction between flow records and packet >> records, you might like this idea: >> We had a similar problem when specifying how to export records of >> filtered flow aggregates in draft-dressler-ipfix-aggregation. We =20 >> solved >> this by using a new template set (Data Template) which is =20 >> announced with >> Set ID=3D4. >> This could also be a solution to distinguish between flow records and >> packet records: Use another Set ID (e.g. 5) to define a PSAMP =20 >> Template >> Set. The format of the set would be the same as for normal (flow) >> Template Sets (Set ID=3D2), but the collector would know that the = data >> originates from a PSAMP probe. >> Regards, >> Gerhard >> Juergen Quittek wrote: >>> Gerhard, >>> >>> Let me add further clarification. >>> >>> I am not necessarily requesting that a single >>> flow record contains means for distinguishing >>> between a flow record and a packet record. >>> Such information could also be communicated >>> in the template or in an option record. >>> >>> However, there is a semantic difference between >>> a packet record and a flow record. Even if a packet >>> record and a flow record are identical for every bit >>> they contain, the contained information is different. >>> Therefore, I want a collector to be able to >>> distinguish between them. >>> >>> This is certainly not a problem for records >>> containing a packet counter. But IPFIX allows flow >>> records that do not have packet counters. In such >>> a case the collector needs further information >>> about the received data. >>> >>> Since IPFIX is the base protocol, I would see a flow >>> record as the default case that does not need any >>> specific tag. But for packet records I would like >>> to see a means that clearly identifies them as such. >>> >>> Thanks, >>> >>> Juergen >>> >>> >>> --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >>> >>>> Dear Juergen, >>>> >>>> I would say it is not a problem since a flow template/record =20 >>>> usually >>>> contains a packet counter. >>>> >>>> However, we could recommend to export the packet counter within =20 >>>> flow >>>> records if PSAMP and IPFIX data are exported by the same =20 >>>> Exporter (or >>>> from the same Observation Domain). >>>> >>>> A related question is if it is allowed having packet counter and =20= >>>> payload >>>> in the same record. If yes, how do you interprete the payload? =20 >>>> Is it the >>>> payload of the first packet in the flow? >>>> Or is this issue already clarified in the PSAMP specifications? >>>> >>>> Regards, >>>> Gerhard >>>> >>>> Juergen Quittek wrote: >>>>> Dear all, >>>>> >>>>> I am very happy that the IPFIX protocol has passed IESG evaluation >>>>> and will >>>>> enter the RFC editor queue. Now we can have the PSAMP protocol >>>>> following >>>>> quickly. >>>>> >>>>> I think that draft-ietf-psamp-protocol-07.txt is in very good =20 >>>>> shape. >>>>> There is only one issue I would like to discuss before =20 >>>>> submitting it >>>>> to our AD with a request for publication. Please send a =20 >>>>> message to >>>>> this list if yo see further issues. >>>>> >>>>> The issue is distinguishing PSAMP and IPFIX reports. >>>>> >>>>> An IPFIX flow report contains information about one or more =20 >>>>> packets >>>>> while a PSAMP report contains information about exactly one =20 >>>>> packet. >>>>> There is no problem with this if the report contains a packet =20 >>>>> counter. >>>>> But if not, it might be unclear if, for example, an octet counter >>>>> indicates the number of octets of a flow or the number of =20 >>>>> octets of >>>>> a single packet. Therefore, I would like to have a means to =20 >>>>> distinguish >>>>> packet reports from flow reports. >>>>> >>>>> Does anyone have a good suggestion for solving this problem? >>>>> >>>>> Or does anyone think that is not a problem? >>>>> >>>>> Input is highly appreciated, because it will help completing >>>>> the PSAMP protocol soon. >>>>> >>>>> Thanks, >>>>> >>>>> Juergen >>>>> >>>>> >>>>> _______________________________________________ >>>>> PSAMP mailing list >>>>> PSAMP@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/psamp >>>> --=20 >>>> Dipl.-Ing. Gerhard M=FCnz >>>> Computer Networks and Internet >>>> Wilhelm Schickard Institute for Computer Science >>>> University of Tuebingen >>>> Sand 13 (Room B309), D-72076 Tuebingen, Germany >>>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>>> E-mail: muenz@informatik.uni-tuebingen.de >>>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >>>> >>> >> ---------------------------------------------------------------------=20= >> --- >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp > > _______________________________________________ > PSAMP mailing list > PSAMP@ietf.org > https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Nov 14 04:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuYb-00048H-Tq; Tue, 14 Nov 2006 04:26:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjuYa-00048C-U8 for psamp@ietf.org; Tue, 14 Nov 2006 04:26:16 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjuYY-0003pj-7a for psamp@ietf.org; Tue, 14 Nov 2006 04:26:16 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2006 10:26:15 +0100 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 kAE9QDpO011548; Tue, 14 Nov 2006 10:26:13 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAE9Q24Z016787; Tue, 14 Nov 2006 10:26:02 +0100 (MET) Received: from [10.61.80.39] (ams3-vpn-dhcp4136.cisco.com [10.61.80.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA00706; Tue, 14 Nov 2006 09:26:01 GMT Message-ID: <45598B89.7030108@cisco.com> Date: Tue, 14 Nov 2006 09:25:29 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [PSAMP] completing the PSAMP protocol References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> <4556F8EE.1020504@informatik.uni-tuebingen.de> <4557FDFB.1060906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8022; t=1163496373; x=1164360373; 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=20[PSAMP]=20completing=20the=20PSAMP=20protocol |Sender:=20; bh=aSBSNK0MdiS64GveRcsHtUZc4rYnGb9px91FNnYd/gs=; b=sQV8llaK5eX4pBvM0SzOwel1HvBti1Dy1hihiUm77OlveQ4cL9indjxjAAP1ca5owRJyzKEb qwACHomfigU+ebc2yLqqeoyHk5W2wNl9UjADhD0sQWnNu7LZe/XSIuqg; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Juergen Quittek wrote: >> I'm not convinced that the application is needed in-band. IPFIX is >> a transportation protocol, the application using it should know what >> it's doing. > > To be precise, it's an IP flow information export protocol :-) > Here, we are using it for packet information export. I don't think the usage of IPFIX should be limited by its name. It's a very flexible format and I expect we'll see a number of applications quite soon. >> OTOH, general purpose collectors seems a reasonable idea. So if an >> in-band way of knowing the application is desirable, then I don't >> think using packet counters is explicit enough and new Set IDs are >> going way too far. At that point PSAMP won't even be using IPFIX >> as defined in IPFIX PROTO. > > The point is that it does not cost us much now to avoid confusion. > I do not feel well with opening the possibility that two identical > streams of reports have different meanings without the collector > being able to distinguish. This does not imply that we need to change > the protocol. We may, but IPFIX is rich enough to offer us several > ways of giving the collector additional information on the records. Obviously you feel strongly that a way of explicitly reporting the application is desirable, so by all means let us define how to do so. I agree that we do not have to change or extend the IPFIX protocol to do so, which is why I am against adding new Set IDs as suggested by Gerhard. >> Why can't we just define a new application I.E.? I agree that the >> default application is going to be Flow Export, but IPFIX will have >> a number of application relatively soon. With a new I.E. we can >> send it per data record or in an option scoped to the template. It >> requires no protocol changes, is explicit and can be used flexibly. > > This would be a way to do it. Wouldn't you still call this in-band? Of course. I'm not against in-band communication if it is desirable, and although I don't think it is required by default, I can see why an in-band communication could be useful. A new I.E. is a very small addition to PSAMP. It can explicitly differentiate between single-packet flow records and PSAMP records, and it can be extended to include future applications. I would suggest we have an IANA controlled 32-bit application ID that would usually be RLE'ed down to 1 octet: 0 - Unknown application 1 - Flow Monitoring 2 - PSAMP Regards, Andrew >> Gerhard Muenz wrote: >>> Juergen, >>> >>> Let me first comment the suggestion in your previous mail: >>> >>>> What about sending a packet counter with value 1 in an option template >>>> for packet reports? >>> >>> The problem remains and becomes even worse if you use a flow counter for >>> packet records: If the value is 1, it still might be a normal flow >>> record. >>> >>> The only solution would be to recommend the following: >>> * always use flow counters for flow records, and >>> * never use flow counters for packet records. >>> >>> If you want a stricter distinction between flow records and packet >>> records, you might like this idea: >>> We had a similar problem when specifying how to export records of >>> filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved >>> this by using a new template set (Data Template) which is announced with >>> Set ID=4. >>> This could also be a solution to distinguish between flow records and >>> packet records: Use another Set ID (e.g. 5) to define a PSAMP Template >>> Set. The format of the set would be the same as for normal (flow) >>> Template Sets (Set ID=2), but the collector would know that the data >>> originates from a PSAMP probe. >>> >>> Regards, >>> Gerhard >>> >>> >>> Juergen Quittek wrote: >>>> Gerhard, >>>> >>>> Let me add further clarification. >>>> >>>> I am not necessarily requesting that a single >>>> flow record contains means for distinguishing >>>> between a flow record and a packet record. >>>> Such information could also be communicated >>>> in the template or in an option record. >>>> >>>> However, there is a semantic difference between >>>> a packet record and a flow record. Even if a packet >>>> record and a flow record are identical for every bit >>>> they contain, the contained information is different. >>>> Therefore, I want a collector to be able to >>>> distinguish between them. >>>> >>>> This is certainly not a problem for records >>>> containing a packet counter. But IPFIX allows flow >>>> records that do not have packet counters. In such >>>> a case the collector needs further information >>>> about the received data. >>>> >>>> Since IPFIX is the base protocol, I would see a flow >>>> record as the default case that does not need any >>>> specific tag. But for packet records I would like >>>> to see a means that clearly identifies them as such. >>>> >>>> Thanks, >>>> >>>> Juergen >>>> >>>> >>>> --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >>>> >>>>> Dear Juergen, >>>>> >>>>> I would say it is not a problem since a flow template/record usually >>>>> contains a packet counter. >>>>> >>>>> However, we could recommend to export the packet counter within flow >>>>> records if PSAMP and IPFIX data are exported by the same Exporter (or >>>>> from the same Observation Domain). >>>>> >>>>> A related question is if it is allowed having packet counter and >>>>> payload >>>>> in the same record. If yes, how do you interprete the payload? Is >>>>> it the >>>>> payload of the first packet in the flow? >>>>> Or is this issue already clarified in the PSAMP specifications? >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> Juergen Quittek wrote: >>>>>> Dear all, >>>>>> >>>>>> I am very happy that the IPFIX protocol has passed IESG evaluation >>>>>> and will >>>>>> enter the RFC editor queue. Now we can have the PSAMP protocol >>>>>> following >>>>>> quickly. >>>>>> >>>>>> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >>>>>> There is only one issue I would like to discuss before submitting it >>>>>> to our AD with a request for publication. Please send a message to >>>>>> this list if yo see further issues. >>>>>> >>>>>> The issue is distinguishing PSAMP and IPFIX reports. >>>>>> >>>>>> An IPFIX flow report contains information about one or more packets >>>>>> while a PSAMP report contains information about exactly one packet. >>>>>> There is no problem with this if the report contains a packet >>>>>> counter. >>>>>> But if not, it might be unclear if, for example, an octet counter >>>>>> indicates the number of octets of a flow or the number of octets of >>>>>> a single packet. Therefore, I would like to have a means to >>>>>> distinguish >>>>>> packet reports from flow reports. >>>>>> >>>>>> Does anyone have a good suggestion for solving this problem? >>>>>> >>>>>> Or does anyone think that is not a problem? >>>>>> >>>>>> Input is highly appreciated, because it will help completing >>>>>> the PSAMP protocol soon. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> PSAMP mailing list >>>>>> PSAMP@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/psamp >>>>> -- >>>>> Dipl.-Ing. Gerhard Münz >>>>> Computer Networks and Internet >>>>> Wilhelm Schickard Institute for Computer Science >>>>> University of Tuebingen >>>>> Sand 13 (Room B309), D-72076 Tuebingen, Germany >>>>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>>>> E-mail: muenz@informatik.uni-tuebingen.de >>>>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >>>>> >>>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp From psamp-bounces@ietf.org Tue Nov 14 07:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjwxi-0008KH-Nc; Tue, 14 Nov 2006 07:00:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjwwZ-0007vy-QX for psamp@ietf.org; Tue, 14 Nov 2006 06:59:11 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjwr8-0004Gd-HO for psamp@ietf.org; Tue, 14 Nov 2006 06:53:37 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2006 12:53:34 +0100 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 kAEBrXMu012950; Tue, 14 Nov 2006 12:53:33 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEBrX4Z029005; Tue, 14 Nov 2006 12:53:33 +0100 (MET) Received: from [144.254.153.57] (dhcp-144-254-153-57.cisco.com [144.254.153.57]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA13199; Tue, 14 Nov 2006 11:53:32 GMT Message-ID: <4559AE3C.6060302@cisco.com> Date: Tue, 14 Nov 2006 11:53:32 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [PSAMP] completing the PSAMP protocol References: <113091BD57179D4491C19DA7E10CD69610ADBC@mx1.office> <45543CB4.1080208@informatik.uni-tuebingen.de> <18BC7C0CEB1184FE899A67B5@753F3B888A9969457862729D> <4556F8EE.1020504@informatik.uni-tuebingen.de> <4557FDFB.1060906@cisco.com> <0C7E50B9-68D1-4649-90D8-70A07208F69D@cert.org> In-Reply-To: <0C7E50B9-68D1-4649-90D8-70A07208F69D@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7706; t=1163505213; x=1164369213; 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=20[PSAMP]=20completing=20the=20PSAMP=20protocol |Sender:=20; bh=QsSF904tuarUS7sTIItsGIuT9zKDAskqy+8gWvDReQs=; b=RjRXI7kIaQCeb8Fhkztv8/U1wCHuc8wRPowKcKAjPJKnwNSEV3ADu3cdfFsFdeSxZBM6gmmL j9KwPzzDygfnmkbxPBmsepMT6iV49xenpjGHkRHmtZJO+o/Ye69xdA/P; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: psamp@ietf.org X-BeenThere: psamp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This mailing list is used for discussion within the IETF packet sampling \(PSAMP\) WG" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: psamp-bounces@ietf.org Brian Trammell wrote: > Andrew, > > I agree fully... the use of such an information element shouldn't be > _required_, because in the general case I would suspect that the > application is implicit in the identity and configuration of the > Collecting and Exporting Processes. Absolutely. I presume you second the motion of a new IE for the application. All in favour say "Aye!" :-) > For our own applications, we've generally used the presence of certain > IEs (packet count for flows, flow count for aggregates) to define the > application as mentioned elsewhere in this thread. However, in those > cases in which it isn't possible to divine the application from > out-of-band configuration or the template, it's quite useful to be able > to represent the record type in-band. OK, so you agree with Jeurgen that we need this. > (Note also, this is very much parallel to the problem of representing > direction selection method for biflows.) Why? Because it's usually available out-of-band but sometimes it would be useful to be explicitly in-band? How to solve this... I know, use a new I.E. :-) Cheers Andrew > On Nov 13, 2006, at 12:09 AM, Andrew Johnson wrote: > >> Hi all >> >> I'm not convinced that the application is needed in-band. IPFIX is >> a transportation protocol, the application using it should know what >> it's doing. >> >> OTOH, general purpose collectors seems a reasonable idea. So if an >> in-band way of knowing the application is desirable, then I don't >> think using packet counters is explicit enough and new Set IDs are >> going way too far. At that point PSAMP won't even be using IPFIX >> as defined in IPFIX PROTO. >> >> Why can't we just define a new application I.E.? I agree that the >> default application is going to be Flow Export, but IPFIX will have >> a number of application relatively soon. With a new I.E. we can >> send it per data record or in an option scoped to the template. It >> requires no protocol changes, is explicit and can be used flexibly. >> >> regards >> >> Andrew >> >> >> >> Gerhard Muenz wrote: >>> Juergen, >>> Let me first comment the suggestion in your previous mail: >>>> What about sending a packet counter with value 1 in an option template >>>> for packet reports? >>> The problem remains and becomes even worse if you use a flow counter for >>> packet records: If the value is 1, it still might be a normal flow >>> record. >>> The only solution would be to recommend the following: >>> * always use flow counters for flow records, and >>> * never use flow counters for packet records. >>> If you want a stricter distinction between flow records and packet >>> records, you might like this idea: >>> We had a similar problem when specifying how to export records of >>> filtered flow aggregates in draft-dressler-ipfix-aggregation. We solved >>> this by using a new template set (Data Template) which is announced with >>> Set ID=4. >>> This could also be a solution to distinguish between flow records and >>> packet records: Use another Set ID (e.g. 5) to define a PSAMP Template >>> Set. The format of the set would be the same as for normal (flow) >>> Template Sets (Set ID=2), but the collector would know that the data >>> originates from a PSAMP probe. >>> Regards, >>> Gerhard >>> Juergen Quittek wrote: >>>> Gerhard, >>>> >>>> Let me add further clarification. >>>> >>>> I am not necessarily requesting that a single >>>> flow record contains means for distinguishing >>>> between a flow record and a packet record. >>>> Such information could also be communicated >>>> in the template or in an option record. >>>> >>>> However, there is a semantic difference between >>>> a packet record and a flow record. Even if a packet >>>> record and a flow record are identical for every bit >>>> they contain, the contained information is different. >>>> Therefore, I want a collector to be able to >>>> distinguish between them. >>>> >>>> This is certainly not a problem for records >>>> containing a packet counter. But IPFIX allows flow >>>> records that do not have packet counters. In such >>>> a case the collector needs further information >>>> about the received data. >>>> >>>> Since IPFIX is the base protocol, I would see a flow >>>> record as the default case that does not need any >>>> specific tag. But for packet records I would like >>>> to see a means that clearly identifies them as such. >>>> >>>> Thanks, >>>> >>>> Juergen >>>> >>>> >>>> --On 10.11.06 09:47 +0100 Gerhard Muenz wrote: >>>> >>>>> Dear Juergen, >>>>> >>>>> I would say it is not a problem since a flow template/record usually >>>>> contains a packet counter. >>>>> >>>>> However, we could recommend to export the packet counter within flow >>>>> records if PSAMP and IPFIX data are exported by the same Exporter (or >>>>> from the same Observation Domain). >>>>> >>>>> A related question is if it is allowed having packet counter and >>>>> payload >>>>> in the same record. If yes, how do you interprete the payload? Is >>>>> it the >>>>> payload of the first packet in the flow? >>>>> Or is this issue already clarified in the PSAMP specifications? >>>>> >>>>> Regards, >>>>> Gerhard >>>>> >>>>> Juergen Quittek wrote: >>>>>> Dear all, >>>>>> >>>>>> I am very happy that the IPFIX protocol has passed IESG evaluation >>>>>> and will >>>>>> enter the RFC editor queue. Now we can have the PSAMP protocol >>>>>> following >>>>>> quickly. >>>>>> >>>>>> I think that draft-ietf-psamp-protocol-07.txt is in very good shape. >>>>>> There is only one issue I would like to discuss before submitting it >>>>>> to our AD with a request for publication. Please send a message to >>>>>> this list if yo see further issues. >>>>>> >>>>>> The issue is distinguishing PSAMP and IPFIX reports. >>>>>> >>>>>> An IPFIX flow report contains information about one or more packets >>>>>> while a PSAMP report contains information about exactly one packet. >>>>>> There is no problem with this if the report contains a packet >>>>>> counter. >>>>>> But if not, it might be unclear if, for example, an octet counter >>>>>> indicates the number of octets of a flow or the number of octets of >>>>>> a single packet. Therefore, I would like to have a means to >>>>>> distinguish >>>>>> packet reports from flow reports. >>>>>> >>>>>> Does anyone have a good suggestion for solving this problem? >>>>>> >>>>>> Or does anyone think that is not a problem? >>>>>> >>>>>> Input is highly appreciated, because it will help completing >>>>>> the PSAMP protocol soon. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> PSAMP mailing list >>>>>> PSAMP@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/psamp >>>>> --Dipl.-Ing. Gerhard Münz >>>>> Computer Networks and Internet >>>>> Wilhelm Schickard Institute for Computer Science >>>>> University of Tuebingen >>>>> Sand 13 (Room B309), D-72076 Tuebingen, Germany >>>>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>>>> E-mail: muenz@informatik.uni-tuebingen.de >>>>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >>>>> >>>> >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> PSAMP mailing list >>> PSAMP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/psamp >> >> _______________________________________________ >> PSAMP mailing list >> PSAMP@ietf.org >> https://www1.ietf.org/mailman/listinfo/psamp _______________________________________________ PSAMP mailing list PSAMP@ietf.org https://www1.ietf.org/mailman/listinfo/psamp