From owner-psamp@ops.ietf.org Thu Jul 1 10:03:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28892 for ; Thu, 1 Jul 2004 10:03:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bg20p-00061C-35 for psamp-data@psg.com; Thu, 01 Jul 2004 13:54:03 +0000 Received: from [195.37.70.2] (helo=tokyo.netlab.nec.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bg20n-00060k-AR for psamp@ops.ietf.org; Thu, 01 Jul 2004 13:54:01 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 4C79C2C90D; Thu, 1 Jul 2004 15:54:00 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 80DED14AD49; Thu, 1 Jul 2004 15:53:58 +0200 (CEST) Date: Thu, 01 Jul 2004 15:54:15 +0200 From: Juergen Quittek To: duffield@research.att.com, psamp@ops.ietf.org Subject: RE: Open issues on PSAMP framework Message-ID: <2147483647.1088697255@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Nick, Thanks for compiling the list. Please find my comments inline --On 24.06.2004 1:27 h -0400 duffield@research.att.com wrote: > Juergen, > > Here is a list of the major open issues raised in the messages that you > referenced, plus proposals for their resolution. In some cases > alternative resolutions are proposed. > > I encourage mailing list participant to send comments to the list so > that we can converge. > > A number of smaller stylistic issues raised are not listed, but will be > taken into account in the revision. > > Nick > > --- > > > FW-0: Document type. > The AD and WG Chairs have agreed that the framework document will be > informational. RESOLVED > > FW-1: References to other PSAMP documents. > Proposal: Include a section describing the role of the other wg > documents. Use more informative labels for references: [PSAMP-PROTO] > protocol document, [PSAMP-MIB] MIB document, [PSAMP-TECH] sampling > techniques, [PSAMP-INFO] information model document. > > Question: can the other PSAMP drafts be included as normative references > while they are yet to be completed? Yes, they can. Giving an overview of the documents that are influenced by the framework is a good idea. But referencing them in any way will most probably make the document stuck in the RFC editor queue until all references also achieve RFC status. This might be a challenge for the patience of the authors, but it is not bad in general. Since the other documents will reference the framework in turn, then all PSAMP documents would be published at once. I would prefer referencing the other documents as RFCs with placeholders for the so far unknown numbers. > FW-2: Terminology section. > Proposal: arrange items in alphabetic order. Use initial upper cases for > terms. Fine with me. But I do not see strong reasons for one way or another. This should be decided by the editors. > FW-3: Requirements. > Proposal: emphasize high level generic requirements (current Section 3) > vs. detailed requirements (following sections). Because document is > informational, use lower cast must, should and may. > FW-4: Architecture. > Proposal: separate out a new architecture section. (The current section > 2 attempts too much by describing architecture by means of the > terminology list). Arrange architecture diagram on a single page. > Include new diagrams of components of measurement process. I support the proposal. > FW-5: Packet selection terminology (Sec 4.1). > The normative selection terminology reference for PSAMP will be > [PSAMP-TECH]. Some, but not all, terms from [PSAMP-TECH] are used in the > framework draft. > Alternative Proposals: > . FW-5a: Duplicate all terminology from [PSAMP-TECH] > . FW-5b: Duplicate only those terms used in the framework document > . FW-5c: Duplicate no terms and refer to [PSAMP-TECH] for definitions I do not like alternative a. I am fine with b and c. b makes this document easier to read on its own. c avoids consistency checking. I have a weak preference for b. > FW-6: Packet Selection Operations (Sec 4.2) > The normative selection operation reference for PSAMP will be > [PSAMP-TECH]. Operations defined in [PSAMP-TECH] are also summarized in > the framework draft. > Proposal: retain current summary descriptions of selection operations. > Omit material from 4.2 on applications of hash based sampling; this now > occurs in [PSAMP-TECH]. Fine with me. > FW-7: Packet Report and Packet Interpretation. > > While PSAMP will use IPFIX, the PSAMP terms (packet report and packet > interpretation) are not used in IPFIX. But the meaning appears > compatible with IPFIX (see Major Point 9 in > https://psg.com/lists/psamp/psamp.2004/msg00024.html ) > > Alternate Proposals: > FW-7a: retain psamp terminology, add section on correspondence with > IPFIX > FW-7b: omit psamp terminology and convert to IPFIX. This is probably > best long term. But would slow down convergence of the document since > (i) it would be a major change, and (ii) IPFIX is still in flux. I have a clear preference for alternative a. PSAMP uses the IPFIX protocol, but the IPFIX terminology is not useful in some sections of the PSAMP documents. I would rather like a clean and consistent set of PSAMP documents than a terminology mix. Maybe, we should request the IPFIX group to generalize their terminology in a way that fits both groups? > FW-8: Transport Protocol. > Proposal: Section 7 to undergo major updates to reflect (i) choice of > IPFIX for PSAMP; (ii) apparent compatibility of IPFIX export protocol > choices (see > http://ipfix.doit.wisc.edu/archive/2377.html) with psamp requirements. > Section 7.7 on collector based rate reconfiguration will be omitted. > > Question: is SCTP-PR a MUST in IPFIX? Yes, it is. > FW-9: Proposal: Omit Section 4.6 > > FW-10: Packet reports. Proposal: definition in Section 2 to be modified > to include e.q. sequence numbers. > > FW-11: Input sequence numbers. > Proposal: include input sequence numbers for each selector in a > composite. > > FW-12: Selection State. > Proposal: selection state to be associated with a packet (e.g. for > reporting) is post-processing of the packet. > > FW-13: Style. > Proposal: Streamline document to retain basic motivation while pruning > longer justifications (e.g. Section 10) . > > FW-14: PSAMP device. > Proposal: define analogously to IPFIX. Sounds like a good choice. Thanks, Juergen >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: Thursday, May 13, 2004 3:54 AM >> To: psamp@ops.ietf.org >> Cc: dchiou@avici.com; bclaise@cisco.com; Duffield,Nicholas G (Nick); >> Greenberg,Albert G (Albert); matthias.grossglauser@epfl.ch; >> peram@cisco.com; Rexford,Jennifer L (Jennifer); gsadasiv@cisco.com >> Subject: Open issues on PSAMP framework >> >> Dear all, >> >> I really would like to close WG last call on the PSAMP framework soon. >> >> Still there is a non-trivial list of open issues that have not been >> closed on the mailing list. I am referring to issues raised in the >> following messages: >> >> https://psg.com/lists/psamp/psamp.2004/msg00024.html >> https://psg.com/lists/psamp/psamp.2004/msg00025.html >> https://psg.com/lists/psamp/psamp.2004/msg00026.html (and > follow-ups) >> https://psg.com/lists/psamp/psamp.2004/msg00030.html >> >> Please have a look at these issues and help finishing the Document! >> >> Nick, at least you as document editor (or one of your seven > co-authors) >> should reply on the raised issues and suggest a solution for each one. >> >> Thanks, >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 > 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.ccrle.nec.de >> > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Sun Jul 11 14:25:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05327 for ; Sun, 11 Jul 2004 14:25:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjirR-0002Uh-Vu for psamp-data@psg.com; Sun, 11 Jul 2004 18:15:37 +0000 Received: from [195.37.70.2] (helo=tokyo.netlab.nec.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjirQ-0002UQ-A4 for psamp@ops.ietf.org; Sun, 11 Jul 2004 18:15:36 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id EC18D2C90C for ; Sun, 11 Jul 2004 19:46:27 +0200 (CEST) Received: by venus.office (Postfix on SuSE Linux eMail Server 3.0, from userid 30) id E89AD1504CA; Sun, 11 Jul 2004 19:46:26 +0200 (CEST) X-Accept-Language: de, en X-Priority: 3 (Normal) X-Mailer: SKYRiXgreen_3.1 NGMime_4.2.45 From: "Thomas Dietz" MIME-Version: 1.0 subject: Improvements for the sample tech document To: psamp@ops.ietf.org Organization: NEC Europe Ltd. content-type: text/plain; charset="iso-8859-1" date: Sun, 11 Jul 2004 19:46:26 +0200 content-transfer-encoding: 7bit Message-Id: <20040711174626.E89AD1504CA@venus.office> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hallo, my name is Thomas Dietz and I am the editor of the PSAMP info model and MIB draft. I am currently reviewing my drafts for the changes made especially in the sample tech document. Reviewing the document I encountered some problems with the filtering techniques. I have some trouble with the information model defined in the sampling tech document. I think that these bit specifications combined with the selection intervals is not really easy to understand and has several disadvantages: * to encode many selection interval into one information model field is very complicated to encode and thus also very complicated to decode at the receiver * always encoding a complete header bitfield (20 bytes IPv4, 40 bytes IPv6) will create very large fields while exporting the filtering options from the sampling node * defining the header as a fixed number of bytes is (at least within IPv6) not right, because the header may have several extension headers * you may want to filter on some specify transport layer fields like tcp/udp port or icmp type: filtering on these gets very difficult especially in the IPv6 case because you don't exactly know where the transport header starts. * filtering on extension headers in IPv6 is also very tedious with the current approach I would prefer to concentrate one some header characteristics like * network protocol (IPv4, IPv6, IPX, Appletalk...) * transport layer protocol (TCP, UDP, SCTP, ICMP...) * transport layer dst/src port (if applicable) * IPv4/v6 dst/src address I know that the above is far of being complete but I don't think we need to have every single header field in the basic standard. If a vendor really needs some more fields he/she can define the fields and extend the info model. Most of the fields I mentioned above are computed in current hardware products anyway, because most of the products support filtering mechanisms. So using these fields also for exporting packet samples would imply a rather small overhead for the manufacturer. On the other hand implementing a bitfield computation as you propose currently is not that common in the current products and has to be implemented from scratch which consumes additional memory and is error prone. I also dislike the idea of several ranges within one filter. I would rather define at most one range per filter and add another filter after the previous one. This would as well as the proposal above improve the readability and is much easier to specify in the info model. It keeps exporting option data/templates small and fast. Furthermore, if the info model is easy to understand it will also be easy to implement. It would be great if we could improve the sample tech document in a way that makes it easy and fast to implement. Best Regards, Thomas -- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Jul 14 07:03:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08783 for ; Wed, 14 Jul 2004 07:03:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkhOx-0000xL-TS for psamp-data@psg.com; Wed, 14 Jul 2004 10:54:15 +0000 Received: from [195.37.70.2] (helo=tokyo.netlab.nec.de) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bkgm3-000Muf-Cp for psamp@ops.ietf.org; Wed, 14 Jul 2004 10:14:04 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id ABC2B2C928 for ; Wed, 14 Jul 2004 12:14:02 +0200 (CEST) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 375BF144623 for ; Wed, 14 Jul 2004 12:14:02 +0200 (CEST) Message-ID: <40F50769.6070603@ccrle.nec.de> Date: Wed, 14 Jul 2004 12:14:01 +0200 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psamp@ops.ietf.org Subject: Re: Improvements for the sample tech document References: <20040711174626.E89AD1504CA@venus.office> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, being probably the first one really reasoning about how to write an info model for the PSAMP exporting (and how an implementation can follow it) you're the first one stepping in the (unresolved) issue of which syntax to use for describing a filter. This was already raised at the IETF in Wien 1 Year ago. To summarize it: there are two options about how to describe a filter: 1) describe it with a "high level" syntax (like the one you propose) probably easy to implement and to export, that can build on existing common practice and code, but with the risk that it is "incomplete" and has to be proprietarily extended to match each vendors' implemented filtering rules (thus risking low interoperability) 2) describe it with a "low level" syntax, in which whatever high level syntax can be translated (thus 100% interoperable and complete), with the (limited??) drawback of bigger exporting overhead and the (big??) drawback of needing to write, on each equipment, the code that converts the description of a propriatery high level filter into that one? Just to explain the current situation: in the absence of a decision, I described in the sample tech draft the low level syntax only, but I'm not engaged to it... If we want to take the other approach fine, but in this case the group should reach some agreement of what this syntax should look like. Thomas stated his proposal, but it's necessary to have a more extensive discussion on it. In particular, other vendors should state what their common practice in filtering is (which fields do you filter on? can you define masks, intervals, etc.?.). The group should also decide if 1) and 2) are mutually exclusive, and if not what is MUST, what SHOULD and MAY..... After that, it makes sense to change the sample tech draft. Maurizio Thomas Dietz wrote: >Hallo, > >my name is Thomas Dietz and I am the editor of the PSAMP info model >and MIB draft. I am currently reviewing my drafts for the changes made >especially in the sample tech document. Reviewing the document I encountered >some problems with the filtering techniques. I have some trouble with >the information model defined in the sampling tech document. > >I think that these bit specifications combined with the selection intervals >is not really easy to understand and has several disadvantages: > >* to encode many selection interval into one information model field is very > complicated to encode and thus also very complicated to decode at the > receiver >* always encoding a complete header bitfield (20 bytes IPv4, 40 bytes IPv6) > will create very large fields while exporting the filtering options from > the sampling node >* defining the header as a fixed number of bytes is (at least within IPv6) > not right, because the header may have several extension headers >* you may want to filter on some specify transport layer fields like > tcp/udp port or icmp type: filtering on these gets very difficult especially > in the IPv6 case because you don't exactly know where the transport header > starts. >* filtering on extension headers in IPv6 is also very tedious with the current > approach > >I would prefer to concentrate one some header characteristics like > > * network protocol (IPv4, IPv6, IPX, Appletalk...) > * transport layer protocol (TCP, UDP, SCTP, ICMP...) > * transport layer dst/src port (if applicable) > * IPv4/v6 dst/src address > >I know that the above is far of being complete but I don't think we need to >have every single header field in the basic standard. If a vendor really needs >some more fields he/she can define the fields and extend the info model. Most >of the fields I mentioned above are computed in current hardware products >anyway, because most of the products support filtering mechanisms. So using >these fields also for exporting packet samples would imply a rather small >overhead for the manufacturer. On the other hand implementing a bitfield >computation as you propose currently is not that common in the current >products >and has to be implemented from scratch which consumes additional memory and is >error prone. > >I also dislike the idea of several ranges within one filter. I would rather >define at most one range per filter and add another filter after the previous >one. This would as well as the proposal above improve the readability and >is much easier to specify in the info model. It keeps exporting option >data/templates small and fast. > >Furthermore, if the info model is easy to understand it will also be easy to >implement. > >It would be great if we could improve the sample tech document in a way that >makes it easy and fast to implement. > >Best Regards, > >Thomas > > -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Jul 14 17:44:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25414 for ; Wed, 14 Jul 2004 17:44:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkrSF-000CPo-AO for psamp-data@psg.com; Wed, 14 Jul 2004 21:38:19 +0000 Received: from [130.216.190.11] (helo=smtpa.itss.auckland.ac.nz) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkrPC-000ByL-5j for psamp@ops.ietf.org; Wed, 14 Jul 2004 21:35:10 +0000 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 8F14B3445D; Thu, 15 Jul 2004 09:35:08 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19824-11; Thu, 15 Jul 2004 09:35:08 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 78C85340F0; Thu, 15 Jul 2004 09:35:08 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i6ELUAo14015; Thu, 15 Jul 2004 09:30:10 +1200 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Thu, 15 Jul 2004 09:30:10 +1200 Message-ID: <1089840610.647e74c6ffe61@webmail.auckland.ac.nz> Date: Thu, 15 Jul 2004 09:30:10 +1200 From: Nevil Brownlee To: Maurizio Molina Cc: psamp@ops.ietf.org Subject: Re: Improvements for the sample tech document References: <20040711174626.E89AD1504CA@venus.office> <40F50769.6070603@ccrle.nec.de> In-Reply-To: <40F50769.6070603@ccrle.nec.de> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Thomas: I think Maurzio summarised 'filtering rules' well. > To summarize it: > there are two options about how to describe a filter: > 1) describe it with a "high level" syntax (like the one you propose) > probably easy to implement and to export, that can build on existing > common practice and code, but with the risk that it is "incomplete" and > has to be proprietarily extended to match each vendors' implemented > filtering rules (thus risking low interoperability) > 2) describe it with a "low level" syntax, in which whatever high level > syntax can be translated (thus 100% interoperable and complete), with > the (limited??) drawback of bigger exporting overhead and the (big??) > drawback of needing to write, on each equipment, the code that converts > the description of a propriatery high level filter into that one? > > Just to explain the current situation: in the absence of a decision, I > described in the sample tech draft the low level syntax only, but I'm > not engaged to it... > If we want to take the other approach fine, but in this case the group > should reach some agreement of what this syntax should look like. Thomas > stated his proposal, but it's necessary to have a more extensive > discussion on it. In particular, other vendors should state what their > common practice in filtering is (which fields do you filter on? can you > define masks, intervals, etc.?.). > > The group should also decide if 1) and 2) are mutually exclusive, and if > not what is MUST, what SHOULD and MAY..... As another example of current practice, you might have a look at RTFM's Simple Ruleset Language, RFC 2723. SRL uses simple (equality under mask) tests of RTFM attribute values from the packet. Using the RTFM attributes to select fields from the packet has the advantage that they're well defined, and RTFM's IANA considerations (in RFC 2722) saying how new attributes can be added. It has the disadvantage that it was built on top of the RTFM packet matching engine, which is very general, and hence difficult (but certainly not impossible) to implement in a high-speed metering system. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Jul 22 15:51:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21629 for ; Thu, 22 Jul 2004 15:51:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnjWm-000Kyf-JB for psamp-data@psg.com; Thu, 22 Jul 2004 19:46:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnjWl-000KyK-I6 for psamp@ops.ietf.org; Thu, 22 Jul 2004 19:46:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20570; Thu, 22 Jul 2004 15:46:49 -0400 (EDT) Message-Id: <200407221946.PAA20570@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-psamp-framework-06.txt Date: Thu, 22 Jul 2004 15:46:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : A Framework for Passive Packet Measurement Author(s) : N. Duffield Filename : draft-ietf-psamp-framework-06.txt Pages : 30 Date : 2004-7-22 This document specifies a framework for the PSAMP (Packet Sampling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized reports, form ra stream of reports on the selected packets, and to export that stream to a collector. This framework details the components of this architecture, then describes some generic requirements, motivated the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting and export are described, along with configuration of the PSAMP functions. Comments on this document should be addressed to the PSAMP Working Group mailing list: psamp@ops.ietf.org To subscribe: psamp-request@ops.ietf.org, in body: subscribe Archive: https://ops.ietf.org/lists/psamp/ A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-framework-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-framework-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-framework-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145620.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Jul 22 15:52:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21693 for ; Thu, 22 Jul 2004 15:52:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnjXA-000L5H-5w for psamp-data@psg.com; Thu, 22 Jul 2004 19:47:16 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnjX9-000L52-60 for psamp@ops.ietf.org; Thu, 22 Jul 2004 19:47:15 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20634; Thu, 22 Jul 2004 15:47:12 -0400 (EDT) Message-Id: <200407221947.PAA20634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-psamp-mib-03.txt Date: Thu, 22 Jul 2004 15:47:12 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : Definitions of Managed Objects for Packet Sampling Author(s) : T. Dietz, B. Claise Filename : draft-ietf-psamp-mib-03.txt Pages : 42 Date : 2004-7-22 This memo defines managed objects for packet sampling. These objects provide information about managed nodes supporting packet sampling, including packet sampling capabilities, configuration and statistics. They also allow to configure packet sampling concerning the IP interface at which packets are sampled, the packet selections methods used for sampling, and the collector to which packet samples are exported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-mib-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-mib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-mib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145626.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Jul 22 15:52:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21777 for ; Thu, 22 Jul 2004 15:52:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnjXZ-000LBN-Db for psamp-data@psg.com; Thu, 22 Jul 2004 19:47:41 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnjXY-000LAt-7v for psamp@ops.ietf.org; Thu, 22 Jul 2004 19:47:40 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20704; Thu, 22 Jul 2004 15:47:37 -0400 (EDT) Message-Id: <200407221947.PAA20704@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: psamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-psamp-info-02.txt Date: Thu, 22 Jul 2004 15:47:37 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Packet Sampling Working Group of the IETF. Title : Information Model for Packet Sampling Exports Author(s) : T. Dietz, et al. Filename : draft-ietf-psamp-info-02.txt Pages : 22 Date : 2004-7-22 This document defines an information and data model for the Packet Sampling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the sampling process. The model is an extension to IPFIX information model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-psamp-info-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-psamp-info-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-7-22145631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-psamp-info-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-psamp-info-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145631.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Jul 29 12:02:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20746 for ; Thu, 29 Jul 2004 12:02:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqDBv-0006ro-AU for psamp-data@psg.com; Thu, 29 Jul 2004 15:51:35 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqDBk-0006qQ-OD for psamp@ops.ietf.org; Thu, 29 Jul 2004 15:51:24 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 29 Jul 2004 08:49:00 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6TFmA3E007251; Thu, 29 Jul 2004 08:48:20 -0700 (PDT) Received: from abierman-w2k01.cisco.com (sjc-vpn2-83.cisco.com [10.21.112.83]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id AXN68361; Thu, 29 Jul 2004 08:48:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20040729084811.025388e0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jul 2004 08:49:31 -0700 To: agenda@ietf.org From: Andy Bierman Subject: PSAMP WG meeting agenda for IETF #60 Cc: psamp@ops.ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_170717388==_" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk --=====================_170717388==_ Content-Type: text/plain; charset="us-ascii" --=====================_170717388==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="psamp_ietf60_agenda.txt" Packet Sampling WG (psamp) IETF #60 Tuesday, August 3, 2004: 0900-1130 =================================== Chairs: Andy Bierman Juergen Quittek AGENDA: Discussion of open issues in all WG drafts 1) Sampling Framework (30 min) - A Framework for Passive Packet Measurement 2) Packet Selection (30 min) - Sampling and Filtering Techniques for IP Packet Selection 3) Report Format and Export Protocol (30 min) - Packet Sampling (PSAMP) Protocol Specifications 4) PSAMP Information Model (30 min) - Information Model for Packet Sampling Exports 5) PSAMP MIB (30 min) - Definitions of Managed Objects for Packet Sampling INTERNET DRAFTS: A Framework for Passive Packet Measurement http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-06.txt Sampling and Filtering Techniques for IP Packet Selection http://www.ietf.org/internet-drafts/draft-ietf-psamp-sample-tech-04.txt Packet Sampling (PSAMP) Protocol Specifications http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-01.txt Information Model for Packet Sampling Exports http://www.ietf.org/internet-drafts/draft-ietf-psamp-info-02.txt Definitions of Managed Objects for Packet Sampling http://www.ietf.org/internet-drafts/draft-ietf-psamp-mib-03.txt --=====================_170717388==_-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Jul 30 07:42:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00801 for ; Fri, 30 Jul 2004 07:42:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqVgC-000LbQ-NI for psamp-data@psg.com; Fri, 30 Jul 2004 11:36:04 +0000 Received: from [195.37.70.2] (helo=tokyo.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqVg1-000Lah-A2 for psamp@ops.ietf.org; Fri, 30 Jul 2004 11:35:53 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 11CE82C90D for ; Fri, 30 Jul 2004 13:35:53 +0200 (CEST) Received: from [10.1.1.103] (dietz.office [10.1.1.103]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id B108714B665 for ; Fri, 30 Jul 2004 13:35:51 +0200 (CEST) Date: Fri, 30 Jul 2004 13:35:51 +0200 From: Thomas Dietz To: psamp@ops.ietf.org Subject: changes draft-ietf-psamp-mib-03.txt Message-ID: <44A6B8F501AA6BC870745A19@dietz.office> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, here is the list of changes for the PSAMP MIB draft: * renamed almost all objects to stay below the 32 char limit * removed the ...Next from all parameter set tables The functionality achieved with the ...Next has now moved to a new table in the instance section. * changed the datatype of some objects to reflect the sample tech requirements * added the parameter set table to all sampling and filtering method, even if it is an empty table for consistency * added capabilities to Random n-out-of-N sampling * changed parameter for uniform probabilistic sampling from population/size pair to a single probability value * changed collector group indexing, so we just use the index from the collector table to reference which collectors belong to which group i.e. if the row in the table is there the collector belongs to the collector group. * introduced a new table in the instance group called method chain table: this table uses as a first index the index of the instance table. This index indicates to which instance the method referenced in the row belongs. The second index indicates the order in which the methods a applied for a given instance (in index 1). The method itself is referenced by an object identifier pointing to a row in a parameter set table. This approach has several advantages: o only one parameter set table entry is needed if the same parameter is used for different instances o by using the indexes from other tables the linkage between the tables is automatically established There are still many open issues. Any feedback is very welcome. If somebody has good ideas for solving one of the open issues don't hesitate to make proposal on- or offline. Regards, Thomas -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Fri Jul 30 07:46:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01020 for ; Fri, 30 Jul 2004 07:46:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqVn2-000MTo-IG for psamp-data@psg.com; Fri, 30 Jul 2004 11:43:08 +0000 Received: from [195.37.70.2] (helo=tokyo.netlab.nec.de) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqVmr-000MT6-VD for psamp@ops.ietf.org; Fri, 30 Jul 2004 11:42:58 +0000 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 7C7732C90D for ; Fri, 30 Jul 2004 13:42:57 +0200 (CEST) Received: from [10.1.1.103] (dietz.office [10.1.1.103]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2C55D6C764 for ; Fri, 30 Jul 2004 13:42:57 +0200 (CEST) Date: Fri, 30 Jul 2004 13:42:57 +0200 From: Thomas Dietz To: psamp@ops.ietf.org Subject: changes draft-ietf-psamp-info-02.txt Message-ID: X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, These are the changes for the PSAMP info model draft: * changed the order of some fields to make some things more clear e.g., the fields listing sampling or filtering methods should come before the fields describing the methods and their parameters just for readability. * changed parameter for uniform probabilistic sampling from population/size pair to a single probability value Since there are still open points in the sampling methods draft the changes made for this version are rather limited. When the sampling methods draft is stable then all the fields needed for the implementation of this draft will be added. Your feedback is very welcome, especially if somebody has good ideas to solve some of the open issues listed within the draft. Regards, Thomas -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: