From owner-rtfm@auckland.ac.nz Sat Nov 4 07:25:17 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18589 for ; Sat, 4 Nov 2000 07:25:15 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id XAA25382; Sat, 4 Nov 2000 23:38:42 +1300 (NZDT) Received: from mail.cnt.ru (mweb.cnt.ru [212.15.127.34]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id XAA25377 for ; Sat, 4 Nov 2000 23:38:39 +1300 (NZDT) Received: (qmail 9207 invoked from network); 4 Nov 2000 10:38:32 -0000 Received: from unknown (HELO ignatievam) (212.15.125.60) by mweb.cnt.ru with SMTP; 4 Nov 2000 10:38:32 -0000 Message-ID: <000801c0464b$2f6e6770$3c7d0fd4@ctel.msk.ru> From: "Ignatieva Marina" To: Subject: about fd_export Date: Sat, 4 Nov 2000 13:37:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C04664.54647EC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C04664.54647EC0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Dear All, I decided to use fd_export , but have the next message: line 2: column 2 d_topdus tag 1; Attribute 128 not allowed in column 2 !!! 1 errors in format file! =20 Please, help me, Best regards Marina Ignatieva E-Mail: ignatm@cnt.ru Central Telegraph ISP=20 Moscow, Russia. ------=_NextPart_000_0005_01C04664.54647EC0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Dear All,

I decided to use fd_export , but = have the=20 next message:

line 2: column = 2 d_topdus=20 tag 1;

Attribute 128 not allowed = in column 2=20 !!!
1 errors in format file! =20

Please, help me,

Best regards

Marina = Ignatieva
E-Mail: ignatm@cnt.ru
Central Telegraph ISP =
Moscow, Russia.

------=_NextPart_000_0005_01C04664.54647EC0-- From owner-rtfm@auckland.ac.nz Sat Nov 4 13:09:57 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24714 for ; Sat, 4 Nov 2000 13:09:55 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA02547; Sun, 5 Nov 2000 05:31:26 +1300 (NZDT) Received: from gremlin.ics.uci.edu (mmdf@gremlin.ics.uci.edu [128.195.1.70]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id FAA02541 for ; Sun, 5 Nov 2000 05:31:24 +1300 (NZDT) Received: from DIGGLETS ( digglets.ics.uci.edu [128.200.38.191] ) by gremlin-relay.ics.uci.edu id aa11975 for ; 4 Nov 2000 08:31 PST Reply-To: schakrav@ics.uci.edu MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu From: Sanjeev Chakravarty To: rtfm@auckland.ac.nz MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Subject: General question Date: Sat, 4 Nov 2000 08:29:01 -0800 Message-ID: <003401c0467c$57632be0$bf26c880@DIGGLETS> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C04639.493FEBE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <000801c0464b$2f6e6770$3c7d0fd4@ctel.msk.ru> Importance: Normal Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C04639.493FEBE0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Is it practical to use the Meter Architecture as defined in RFC 2063/2722 in DiffServ Metering inside the TCB? Since the Meter in DiffServ indicates the conformance of packets, maybe a MeterReader can be configured to do that task. Thanks, Sanjeev Chakravarty UCI ------=_NextPart_000_0035_01C04639.493FEBE0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

Is it=20 practical to use the Meter Architecture as defined in RFC 2063/2722 in = DiffServ=20 Metering inside the TCB?

Since the Meter in DiffServ indicates the = conformance=20 of packets, maybe a MeterReader can be configured to do that task.=20

Thanks,

Sanjeev Chakravarty

UCI

------=_NextPart_000_0035_01C04639.493FEBE0-- From owner-rtfm@auckland.ac.nz Tue Nov 7 02:40:38 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07446 for ; Tue, 7 Nov 2000 02:40:36 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id SAA26046; Tue, 7 Nov 2000 18:37:47 +1300 (NZDT) Received: from cs.waikato.ac.nz (taupo.cs.waikato.ac.nz [130.217.241.30]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id SAA26041 for ; Tue, 7 Nov 2000 18:37:46 +1300 (NZDT) Received: (from joerg@localhost) by cs.waikato.ac.nz (8.9.3/8.9.3) id SAA44597; Tue, 7 Nov 2000 18:37:42 +1300 (NZDT) (envelope-from joerg) Date: Tue, 7 Nov 2000 18:37:42 +1300 From: Joerg Micheel To: rtfm@auckland.ac.nz Cc: joerg@cs.waikato.ac.nz Subject: Comments on draft-bullard-pcap-00.txt Message-ID: <20001107183742.B44431@cs.waikato.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Dept of Computer Science, University of Waikato, Hamilton, New Zealand Project: WAND - Waikato Applied Network Dynamics, DAG Operating-System: ... powered by FreeBSD Sender: owner-rtfm@auckland.ac.nz Precedence: bulk This comment is not exhaustive, rather like notest to draft-bullard-pcap-00.txt. I will take the packet structure as outlined in 6.2 as a reference. The document does not mention the type of information stored in the source identifier. It would be helpful to have at least some examples as to what this field is used for. ifIndex and ifType are very specific fields which imply router context for capturing. There are different ways to capture network traffic, some indication as to how these fields should be filled must be made. The use of the status fields is not documented. I would like to understand the use of the length field. I can see a number of different contexts to which length could be applied. First of all, the original size of the packet "on the wire". Second, the size of the packet as it appeared to the "protocol layer observed", as defined in the document. Third, it could be the amount of information present in the trace record ("captured packet information"). This could be counted with or without the fixed header information. Apart from packet length, there might also be an offset. Many links have a fixed overhead that one might want to avoid to save costs. The timestamps should be broken down in seconds and fractions of a second. The reason for that is that one could use the number as a 64bit number for computations. Right now, this number needs conversion for all numerical operations. Using fractions, the resolution becomes roughly 0.25 nanoseconds, not much different from the proposal. The draft does not mention the epoch for the seconds, I assume it is UNIX style (Jan 1st 1970). The format I am proposing is identical to NTP (and RFC's could be referenced), only NTP uses 1st Jan 1900 as the epoch, which is not very useful. Apart from that I think some form of indication for clock accuracy must be given. Some people might intend to use the timestamp for computation with timestamps from other links, it might be worthwhile to know what the accuracy is that can be assumed. This might have to go into some overhead protocol separate from the current encapsulation header. In section 6.3 it is not clear as to whether one captured header will result in one packet being transported via the network, which sounds rather inefficient. I assume several packets get batched up, in which case a protocol is required that defines the layout of multiple header records in one packet as well as a definition as to when can be assumed that all of the packets required up to a certain point in time have arrived at the remote end point. As I said, not exhaustive, just thoughts ... Joerg Micheel -- Joerg B. Micheel Email: WAND and NLANR MOAT Email: The University of Waikato, CompScience Phone: +64 7 8384794 Private Bag 3105 Fax: +64 7 8585095 Hamilton, New Zealand Plan: PMA, TINE and the DAG's From owner-rtfm@auckland.ac.nz Tue Nov 7 18:58:52 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08149 for ; Tue, 7 Nov 2000 18:58:49 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id LAA26847; Wed, 8 Nov 2000 11:11:18 +1300 (NZDT) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id LAA26841 for ; Wed, 8 Nov 2000 11:11:17 +1300 (NZDT) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: Reminder: CFP for PAM2001 Message-ID: Date: Wed, 8 Nov 2000 11:11:24 +1300 (New Zealand Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: PAM2001, a workshop on passive and active measurement techniques for high speed computer networks and the Internet will be held in Amsterdam, April 23-24, 2001. Extended abstracts (about 500 words, plain ASCII preferred) must be submitted by e-mail to pam2001@ripe.net by 12 November 2000 For details see http://www.ripe.net/pam2001 Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From owner-rtfm@auckland.ac.nz Tue Nov 7 18:59:40 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08325 for ; Tue, 7 Nov 2000 18:59:37 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id LAA26537; Wed, 8 Nov 2000 11:09:50 +1300 (NZDT) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id LAA26528; Wed, 8 Nov 2000 11:09:48 +1300 (NZDT) From: Nevil Brownlee To: D.Thomas@imb.uq.edu.au Cc: rtfm@auckland.ac.nz Subject: Re: NetFlow cf RTFM Message-ID: Date: Wed, 8 Nov 2000 11:09:55 +1300 (New Zealand Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello Danny: On Sun, 29 Oct 2000 22:54:46 +1300 (NZDT) owner-rtfm@auckland.ac.nz wrote: > I'm writing a brief description for my faculty on how this uni charges > network traffic. Basically the uni is presented with a bill from AARNet > based on NetFlow accounting in the AARNet routers. However that accounting > is not down to the subnet-level or below, so UQ runs its' own accounting > system. I don't know the details but believe this is based on NeTraMet. The > results don't always agree. > > Anyway for my own interest is there a broad comparison between NetFlow & > RTFM available? ............. > how does the following sound? > > NB NetFlow is somewhat similar to the Real-Time Flow Metering (RTFM) > described in several RFCs and available in the NeTraMet package. > While it's a more general approach than NetFlow, they are sufficiently > close that NeTraMet can act as a data collector for NetFlow routers. .............. > PS are NeTflow & RTFM diverging or converging over timne? As far as I know, no-one's written a comparison between the two. Your paragraph has it the wrong way round. The story is: 1. NeTraMet implements the RTFM architecture, which is a generalised, distributed approach to measuring traffic flows. It's based on the idea that an RTFM meter sees every packet, which can allow the meter to build statistical information about flow behaviours (see RFC 2724) NetFlow summarises flows, sending data records at intervals set by the router configuration. 2. The RTFM Meter MIB is a Proposed Internet Standard (RFC 2720), NetFlow is a widely-used Cisco proprietary scheme for collecting data from Cisco touters and switches. NeTraMet implements the RTFM meter on many different flavours of Unix systems, and on Microsoft Windows. There's no reason why - if RTFM/NeTraMet users would just press their vendors harder (along the lines "why don't you implement RFC 2720???") - the RTFM meter shouldn't be available in switches and routers. 3. NeTraMet includes a version of the RTFM meter which uses NetFlow data as input (instead of looking directly at packet headers) - this is 'NetFlowMet.' This trades off fine time detail (e.g. for 10-second flow rate distributions) against having a meter which can grab NetFlow data from Cisco routers. Used this way, NeTraMet acts as a data collection/consolidation system for NetFlow data, in much the same way as cflowd. The advantage of using NetFlow data as input to NeTraMet is that you can get it from many interfaces on the router (remembering that there is a performance hit on the router when you turn NetFlow on for an interface), wheras with NeTraMet you need a metering point on every network segment you want to measure traffic on. Is that enough info for you? Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From owner-rtfm@auckland.ac.nz Thu Nov 23 13:21:33 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21520 for ; Thu, 23 Nov 2000 13:21:30 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id FAA02138; Fri, 24 Nov 2000 05:36:44 +1300 (NZDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA02132 for ; Fri, 24 Nov 2000 05:36:37 +1300 (NZDT) Received: from wallace.heidelberg.ccrle.nec.de (Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id eANGb3E03486; Thu, 23 Nov 2000 17:37:03 +0100 (CET) Received: from ccrle.nec.de (belem.heidelberg.ccrle.nec.de [192.168.102.178]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA31094; Thu, 23 Nov 2000 17:36:26 +0100 Message-ID: <3A1D4724.DFFCA49B@ccrle.nec.de> Date: Thu, 23 Nov 2000 17:34:44 +0100 From: Juergen Quittek X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: rtfm@auckland.ac.nz CC: mobivas@ccrle.nec.de Subject: I-D on low-level interface to packet capturing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, Georg Carle and myself have posted an Internet draft suggesting extensions to the Remote Packet Capture draft from Carter. You'll find Carter's draft at http://www.ietf.org/internet-drafts/draft-bullard-pcap-00.txt and our draft at http://www.ietf.org/internet-drafts/draft-quittek-pcap-ext-00.txt The extensions we suggest concern the captured packet encapsulation header and the configuration of packet capturing devices. The captured packet encapsulation header is extended by flags indicating simple steps of pre-processing captured packet headers. Most indicated pre-processing actions are merging actions of headers with common properties. For configuration of packet capturing devices, a configuration record is suggested. We would like to present and discuss the draft at the rtfm BOF in San Diego. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., C&C Research Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de