Subject: UNSUBS

From: Mark <[email-masked]>
Date: Tue, 24 Apr 2001 09:35:24 +0100

please unsubscribe me from this list

thank you

mark crompton
creative director
consolidated communications
london
020 7208 2749

	-----Original Message-----
	From:	Carter Bullard [SMTP:[email-masked]]
	Sent:	Monday, April 23, 2001 9:02 PM
	To:	[email-masked]
	Subject:	RE: Standard Flows: Next Move

	Hey Nevil, 
	Sorry for the late reply.  I've been away. 
	This is a great start for this project!  I agree 
	with Dave that IPFX would be a great name.  

	How about including Argus in your list of flow data collection 
	strategies?  Argus was started at CMU in 1992 and has been 
	in the public domain since late 1995.  CMU gave a presentation 
	of Argus-1.3 at an RMON working group meeting in Dec, 1994. 
	It predates NetFlow, LFAP, and RTFM (although not your meter ;o), 
	and Argus had/has many of the qualities that the group 
	is looking to describe; standard flow model for all IP 
	traffic, push and pull data collection models, well defined 
	record generation triggers.  It is currently an ongoing 
	open-source project, mentioned on the Caida web site, referenced 
	by NIST, used in at least one commercial product, etc.... 

	Argus can read Netflow, convert it and redistribute it, if 
	that helps ;o) 

	Carter 

	Carter Bullard 
	QoSient, LLC 
	300 E. 56th Street, Suite 18K 
	New York, New York  10022 

	[email-masked] 
	Phone +1 212 588-9133 
	Fax   +1 212 588-9134 
	http://qosient.com <http://qosient.com>  

	> -----Original Message----- 
	> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]On 
	> Behalf Of Nevil Brownlee 
	> Sent: Sunday, April 15, 2001 4:26 AM 
	> To: [email-masked] 
	> Subject: Standard Flows: Next Move 
	> 
	> 
	> 
	> Hello All: 
	> 
	> Here's my attempt to summarise the Mailing List Discussion so far:

	> 
	> Definition of 'flows' 
	> 
	>   Collection of TCP or UDP microflows that 
	>   - are forwarded along the same common path 
	>   - share the same class of service 
	> 
	> or 
	>   Unidirectional series of IP packets of a given protocol, 
	>   with the same IP Address / Port endpoints, i.e. a 5-tuple. 
	> 
	> 'Common path' is a vague concept (except for a MPLS LSP). 
	> 'Class of service' is also vague (but we could use DSCodepoint). 
	> 
	> Include interface numbers?  Would help with multicast. 
	> 
	> Better not to, should stick with data which can be extracted 
	> directly from packets.  Interfaces can't (an input interface 
	> may not know what the output interface will be), nor can 
	> AS numbers. 
	> 
	> Better to have a minimum 'flow key.'  Could allow for more 
	> data (interface numbers, ASNs, LSPs, etc.) as options. 
	> 
	> Could be useful to keep 'flow definition' separate from 
	> 'flow identification,' e.g. use 5-tuple as definition, 
	> other attributes (IPv6 flow label, FlowID, ifIndex, ...) 
	> 
	> We need to start working on 'Requirements' ... 
	> 
	>         ------------------------------------- 
	> 
	> 
	> I think it's time we started on a draft charter, and of course 
	> we need one or two Internet Drafts to support a BOF request. 
	> 
	> Here's my attempt at a draft WG charter: 
	> 
	> 
	> IP Flow Export (IFX) 
	> 
	> At present there are three public-domain methods in use for 
	> collecting flow data: 
	>  - Netflow (on Cisco routers) 
	>  - LFAP (on Riverstone routers) 
	>  - RTFM (using NeTraMet on Unix boxes) 
	> Flow data is most commonly required for usage measurement, i.e. it

	> is seen as a major component of Accounting, the third A in AAA. 
	> 
	> Several router vendors have expressed strong support for a WG 
	> to develop a standard method of exporting flow data from routers. 
	> A preliminary meeting was held at the Minneapolis IETF meeting 
	> in March, and vigorous discussion has begun on the RTFM mailing 
	> list. 
	> 
	> We believe that the proposed Working Group would fall most
naturally 
	> within the Operations and Management Area.  Its goals and
requirements 
	> are straightforward; the Group should be able to complete its work

	> in about one year. 
	> 
	> 
	> Goals: 
	> 
	>  1. Produce a 'requirements' document.  This will identify the 
	>     target community for SFX, expected uses of flow data, 
	>     and the constraints (reliability, timeliness, level of 
	>     detail, etc.) these uses imply. 
	> 
	>  2. Define 'IP accounting flow,' and a data model for it. 
	> 
	>  3. Specify mechanism(s) for exporting accounting flows. 
	>     These must allow for push and pull models, and be capable 
	>     of handling high volumes of flow data. 
	> 
	>  4. Develop methods of configuring and controlling flow export 
	>     in a network device.  For example, 
	>        a. How much detail is required (level of aggregation)? 
	>        b. Will data be read by the accounting system (pull model)?

	>        c. Or should data be sent to the accounting system at 
	>           specified intervals (push model)? 
	> 
	> Milestones: 
	> 
	>  1. IP Flow Export Requirements (Informational RFC) 
	> 
	>  2. IP Flow Definition and Export Control Mechanisms 
	> (Standards Track RFC) 
	> 
	>  3. Flow Export: Transport Mechanisms (Informational RFC) 
	> 
	> 
	> Is this on the right lines?  What have I left out?  
	> 
	> I think we need an initial version of the Requirements draft, as
soon 
	> as we can manage to produce it.  I'll be away from email for much
of 
	> the next three weeks, but after that I'll be able to put some
effort 
	> into editing such a draft.  So, comments/suggestions please ... 
	> 
	> 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 | 
	> +------------------------------------------------------------- 
	> --------N 
	> 
	> 
	>