From owner-rtfm@auckland.ac.nz  Tue Apr  3 22:16:50 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23303
	for <rtfm-archive@odin.ietf.org>; Tue, 3 Apr 2001 22:16:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id LAA01306;
	Wed, 4 Apr 2001 11:59:17 +1200 (NZST)
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 LAA01288
	for <rtfm@auckland.ac.nz>; Wed, 4 Apr 2001 11:59:15 +1200 (NZST)
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
To: rtfm@auckland.ac.nz
Subject: BOUNCE rtfm@auckland.ac.nz: Non-member submission from [Remco van de Meent <remco@vandemeent.net>] <fwd>
Message-ID: <SIMEON.10104041118.E@n.postbox.auckland.ac.nz>
Date: Wed, 4 Apr 2001 11:59:18 +1200 (New Zealand Standard 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

--- Begin Forwarded Message ---
Date: Wed, 28 Mar 2001 01:29:20 +1200 (NZST)
From: owner-rtfm@auckland.ac.nz
Subject: BOUNCE rtfm@auckland.ac.nz: Non-member submission from [Remco 
van de Meent <remco@vandemeent.net>]
Sender: owner-rtfm@auckland.ac.nz
To: owner-rtfm@auckland.ac.nz

Reply-To: owner-rtfm@auckland.ac.nz
Message-ID: <200103271329.BAA19573@mailhost.auckland.ac.nz>


From rtfm-owner  Wed Mar 28 01:29:19 2001
Received: from cal052204.student.utwente.nl (mail@cal052204.student.utwente.nl [130.89.230.134] (may be forged))
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id BAA19567
	for <rtfm@auckland.ac.nz>; Wed, 28 Mar 2001 01:29:18 +1200 (NZST)
Received: from remco by cal052204.student.utwente.nl with local (Exim 3.12 #1 (Debian))
	id 14htXA-0002zg-00
	for <rtfm@auckland.ac.nz>; Tue, 27 Mar 2001 15:29:16 +0200
Date: Tue, 27 Mar 2001 15:29:15 +0200
From: Remco van de Meent <remco@vandemeent.net>
To: rtfm@auckland.ac.nz
Subject: Re: IP flow def'n: unidirectional, "host pair", "host port quadruple" (was "Re: Standard Flow Export - definition of 'flows'")
Message-ID: <20010327152915.A10531@oloon.student.utwente.nl>
References: <4.3.2.7.1.20010326092734.0374ef08@mordor> <20010326144847.A6526@doit.wisc.edu> <3AC04072.F27B63F1@telin.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AC04072.F27B63F1@telin.nl>; from poortinga@telin.nl on Tue, Mar 27, 2001 at 09:25:38AM +0200
Sender: Remco van de Meent <remco@cal052204.student.utwente.nl>

Remco Poortinga wrote:
> > In my mind, the IP flow definition would go something more along
> > these lines:
> > 
> >    An IP flow is a unidirectional series of IP packets of a given
> >    protocol,
> 
> [insert]
> and Class of Service
> (and maybe more/others if we look at the IPv6 header?)

Is "Class of Service" well-defined? I think a more detailed description
would be useful. Adding CoS to the definition sounds good. However,
some thoughts.

Trying to define CoS. IP packets that have the same TOS and/or DSCP
bits set? Also within other (but possibly irrelevant?) domains, the
proposed 4-tuple itself is used for classification (i.e. setting those
bits) of the service.

I'm trying to think of an example where adding CoS to the definition of
a flow would add to its strength. In other words, a scenario where
classification is not based on parts already mentioned in the proposed
definition for an IP flow. Theoratically, classification could be done
using any of the bits in the IP header, "some" parts of the lower layer
protocol (e.g. transport protocol, ethernet mac address) as well as the
physical environment the IP packet lives in (e.g. the port it has been
received on). In that view adding CoS is useful, IMHO. From a more
practical viewpoint, I'm not really sure. 

> >traveling between a source and destination, within a
> >    certain period of time.
> >    The source and destination are defined, at least, by IP address,
> >    forming a "host pair".
> > 
> >    For IP protocols which further qualify the source and destination
> >    endpoints with a /port/ number, those port numbers become part of
> >    the source and destination, forming a "host and port quadruple"
> >    (source-address, source-port, destination-address,
> >    destination-port).


cheers,
Remco.
--- End Forwarded Message ---


+---------------------------------------------------------------------+
| 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  Sun Apr 15 07:21:29 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08368
	for <rtfm-archive@odin.ietf.org>; Sun, 15 Apr 2001 07:21:27 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id VAA01913;
	Sun, 15 Apr 2001 21:43:53 +1200 (NZST)
Received: from nebbiolo.caida.org (root@ccu1.auckland.ac.nz [130.216.3.1])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id VAA01908
	for <rtfm@auckland>; Sun, 15 Apr 2001 21:43:50 +1200 (NZST)
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Date: Sun, 15 Apr 2001 01:26:29 -0700
To: rtfm@auckland.ac.nz
Subject: Standard Flows: Next Move
Message-ID: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
Priority: NORMAL
X-Mailer: Execmail for Linux 5.1 Build (8)  -- Evaluation Copy
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk


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




From owner-rtfm@auckland.ac.nz  Mon Apr 16 15:52:48 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12680
	for <rtfm-archive@odin.ietf.org>; Mon, 16 Apr 2001 15:52:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id GAA13430;
	Tue, 17 Apr 2001 06:17:07 +1200 (NZST)
Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id GAA13420;
	Tue, 17 Apr 2001 06:16:59 +1200 (NZST)
Received: from gruth (tcpa10.barrnet.net [204.160.74.39])
	by po2.bbn.com (8.9.1/8.9.1) with SMTP id OAA05896;
	Mon, 16 Apr 2001 14:19:46 -0400 (EDT)
From: "Gregory R. Ruth" <gruth@genuity.com>
To: "Nevil Brownlee" <n.brownlee@auckland.ac.nz>, <rtfm@auckland.ac.nz>
Subject: RE: Standard Flows: Next Move
Date: Mon, 16 Apr 2001 14:14:08 -0400
Message-ID: <NFBBLOIEOLBGIBNHOEHBMEGECBAA.gruth@genuity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit

Nevil,
     Your proposed charter sounds fine to me, and the sooner we get
agreement on that and send it to the IESG, the better.  My only reservation
is that one year is only 3 IETFs (4 if you cheat a little) and that seems
such a short time to get a requirements RFC AND a standard RFC done, as the
later may have to wait for good progress on the former.  Nevertheless, our
goals are modest and narrowly defined, and it seems about the right target.
     Do we need to have a BOF before we can get a WG chartered?  Seems like
it might just slow down the process.

Greg

-----Original Message-----
From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On
Behalf Of Nevil Brownlee
Sent: Sunday, April 15, 2001 4:26 AM
To: rtfm@auckland.ac.nz
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



From owner-rtfm@auckland.ac.nz  Tue Apr 17 06:04:55 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04858
	for <rtfm-archive@odin.ietf.org>; Tue, 17 Apr 2001 06:04:54 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA02751;
	Tue, 17 Apr 2001 20:41:48 +1200 (NZST)
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 UAA02724;
	Tue, 17 Apr 2001 20:41:41 +1200 (NZST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3H8gTe08205;
	Tue, 17 Apr 2001 10:42:29 +0200 (CEST)
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 KAA16658;
	Tue, 17 Apr 2001 10:37:39 +0200
Message-ID: <3ADC01C0.D67B139@ccrle.nec.de>
Date: Tue, 17 Apr 2001 10:41:36 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
CC: rtfm@auckland.ac.nz
Subject: Re: Standard Flows: Next Move
References: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Neville,

thanks for the draft charter. I like it very much.
Some comments are inline.

    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


Nevil Brownlee wrote:
> 
> 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,

SFX? You probably mean IFX.

>     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.

We are not going to export the flow, but flow accounting information
Furthermore, some of my colleagues misinterpreted the term "export"
because they associated it with exporting it out of an administrative
domain.

Suggestion:

  3. Specify mechanism(s) for exporting flow accounting information
     out of middleboxes.

>     These must allow for push and pull models, and be capable
>     of handling high volumes of flow data.

Do we really need the pull model? It seems to be a nice option next
to the push model, but I'm not sure. Let's discuss this again when
we  have the requirements completed.

> 
>  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)?

I see b. and c. to be already answered by the requirements.

> 
> Milestones:
> 
>  1. IP Flow Export Requirements (Informational RFC)
> 
>  2. IP Flow Definition and Export Control Mechanisms (Standards Track RFC)

I suggest to split these two documents. An IP flow definition would be a 
more general RFC which might be referenced by many other working groups. 
The export control mechanisms are specific to this future WG. Both documents 
should be able to progress independently.

> 
>  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 ...

... particularly, we need a discussion on requirements!

> 
> 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


From owner-rtfm@auckland.ac.nz  Tue Apr 17 06:21:47 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04988
	for <rtfm-archive@odin.ietf.org>; Tue, 17 Apr 2001 06:21:46 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id VAA04246;
	Tue, 17 Apr 2001 21:05:13 +1200 (NZST)
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 VAA04238;
	Tue, 17 Apr 2001 21:05:09 +1200 (NZST)
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3H95we09838;
	Tue, 17 Apr 2001 11:05:58 +0200 (CEST)
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 LAA16896;
	Tue, 17 Apr 2001 11:01:08 +0200
Message-ID: <3ADC0741.254FB04F@ccrle.nec.de>
Date: Tue, 17 Apr 2001 11:05:05 +0200
From: Juergen Quittek <quittek@ccrle.nec.de>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gregory R. Ruth" <gruth@genuity.com>
CC: Nevil Brownlee <n.brownlee@auckland.ac.nz>, rtfm@auckland.ac.nz
Subject: Re: Standard Flows: Next Move
References: <NFBBLOIEOLBGIBNHOEHBMEGECBAA.gruth@genuity.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello Greg,

"Gregory R. Ruth" wrote:
> 
> Nevil,
>      Your proposed charter sounds fine to me, and the sooner we get
> agreement on that and send it to the IESG, the better.  My only reservation
> is that one year is only 3 IETFs (4 if you cheat a little) and that seems
> such a short time to get a requirements RFC AND a standard RFC done, as the
> later may have to wait for good progress on the former.  Nevertheless, our

I share your concerns. However, the way I see it, the IESG wants to have
in general rather short termed and focussed charters, because the number 
of WGs is already terribly high. Consequently, we should request a WG not 
before we have a clear idea what we want to do, and not before we have some 
(potentially competing) concrete suggestions about the output we are planning 
to produce. This means, we should have a requirements document which is not 
too far from maturity and we should have some initial drafts for the other 
documents.

> goals are modest and narrowly defined, and it seems about the right target.
>      Do we need to have a BOF before we can get a WG chartered?  Seems like
> it might just slow down the process.

That's probably right, but we should make the decision (whether ot ask for
a WG or a BOF) dependent on our progress during the next months. If we can
go on quickly, I agree with you, that we should directly ask for a new WG
(probably referencing the San Diego BOF). But if we go on slowly, I'd prefer
to get some additional input from another more focussed BOF.

    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


From owner-rtfm@auckland.ac.nz  Mon Apr 23 14:01:49 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08685
	for <rtfm-archive@odin.ietf.org>; Mon, 23 Apr 2001 14:01:47 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id EAA18149;
	Tue, 24 Apr 2001 04:28:58 +1200 (NZST)
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id EAA18144;
	Tue, 24 Apr 2001 04:28:54 +1200 (NZST)
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 14rjCI-0006CE-00; Mon, 23 Apr 2001 11:28:22 -0500
Date: Mon, 23 Apr 2001 11:28:22 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Cc: rtfm@auckland.ac.nz
Subject: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next Move")
Message-ID: <20010423112822.A22844@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
References: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>; from n.brownlee@auckland.ac.nz on Sun, Apr 15, 2001 at 01:26:29AM -0700
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-E-INHCHMK, inhibited CHMKernel trap, code=00000000, PC=000004C8, PS=7FED6580
X-Shakespearean-Insult: Thou droning plume-plucked vassal
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

On Sun, Apr 15, 2001 at 01:26:29AM -0700, Nevil Brownlee wrote:
> 
> Hello All:
> 
> Here's my attempt to summarise the Mailing List Discussion so far:
> 
> Definition of 'flows'
> 
>   Collection of TCP or UDP microflows that 

What prior work defines "microflows"?  (For the moment I'm presuming
for TCP that that would be a fragment of a stream.)

>   - 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)

I would prefer "IPFX" to either "IFX" or "SFX".  We should settle on
this ASAP since it is a prerequisite for the BoF prerequisites ;^).

> 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.

Is it relevent to mention that other vendors such as Juniper and
Extreme have adopted the Cisco-defined NetFlow export PDU?

Presumably this is to acheive compatibility with flow collectors, but
since NetFlow is not an Official Standard Protocol, various
implementations do not necessarily use the same flow definition and
therefore do not ensure interoperability of collected accounting data.

I see this as a prime motivating factor for doing this WG _now_.

> 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?  

Overall, I like your outline.
 
Dave

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI


From owner-rtfm@auckland.ac.nz  Mon Apr 23 17:49:07 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13474
	for <rtfm-archive@odin.ietf.org>; Mon, 23 Apr 2001 17:49:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id IAA03360;
	Tue, 24 Apr 2001 08:02:57 +1200 (NZST)
Received: from smtp4ve.mailsrvcs.net (smtp4vepub.gte.net [206.46.170.25])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id IAA03347
	for <rtfm@auckland.ac.nz>; Tue, 24 Apr 2001 08:02:55 +1200 (NZST)
Received: from sphynx (adsl-151-202-199-44.nyc.adsl.bellatlantic.net [151.202.199.44])
	by smtp4ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id UAA23783567
	for <rtfm@auckland.ac.nz>; Mon, 23 Apr 2001 20:18:31 GMT
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: <rtfm@auckland.ac.nz>
Subject: RE: Standard Flows: Next Move
Date: Mon, 23 Apr 2001 16:02:18 -0400
Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CBE5@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0031_01C0CC0E.C6E68B20"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C0CC0E.C6E68B20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


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

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com


> -----Original Message-----
> From: owner-rtfm@auckland.ac.nz [mailto:owner-rtfm@auckland.ac.nz]On
> Behalf Of Nevil Brownlee
> Sent: Sunday, April 15, 2001 4:26 AM
> To: rtfm@auckland.ac.nz
> 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
> 
> 
> 

------=_NextPart_000_0031_01C0CC0E.C6E68B20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: Standard Flows: Next Move</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>Hey Nevil,</FONT>

<BR><FONT SIZE=3D2>Sorry for the late reply.&nbsp; I've been =
away.</FONT>

<BR><FONT SIZE=3D2>This is a great start for this project!&nbsp; I =
agree</FONT>

<BR><FONT SIZE=3D2>with Dave that IPFX would be a great name.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>How about including Argus in your list of flow data =
collection</FONT>

<BR><FONT SIZE=3D2>strategies?&nbsp; Argus was started at CMU in 1992 =
and has been</FONT>

<BR><FONT SIZE=3D2>in the public domain since late 1995.&nbsp; CMU gave =
a presentation</FONT>

<BR><FONT SIZE=3D2>of Argus-1.3 at an RMON working group meeting in Dec, =
1994.</FONT>

<BR><FONT SIZE=3D2>It predates NetFlow, LFAP, and RTFM (although not =
your meter ;o),</FONT>

<BR><FONT SIZE=3D2>and Argus had/has many of the qualities that the =
group</FONT>

<BR><FONT SIZE=3D2>is looking to describe; standard flow model for all =
IP</FONT>

<BR><FONT SIZE=3D2>traffic, push and pull data collection models, well =
defined</FONT>

<BR><FONT SIZE=3D2>record generation triggers.&nbsp; It is currently an =
ongoing</FONT>

<BR><FONT SIZE=3D2>open-source project, mentioned on the Caida web site, =
referenced</FONT>

<BR><FONT SIZE=3D2>by NIST, used in at least one commercial product, =
etc....</FONT>
</P>

<P><FONT SIZE=3D2>Argus can read Netflow, convert it and redistribute =
it, if</FONT>

<BR><FONT SIZE=3D2>that helps ;o)</FONT>
</P>

<P><FONT SIZE=3D2>Carter</FONT>
</P>

<P><FONT SIZE=3D2>Carter Bullard</FONT>

<BR><FONT SIZE=3D2>QoSient, LLC</FONT>

<BR><FONT SIZE=3D2>300 E. 56th Street, Suite 18K</FONT>

<BR><FONT SIZE=3D2>New York, New York&nbsp; 10022</FONT>
</P>

<P><FONT SIZE=3D2>carter@qosient.com</FONT>

<BR><FONT SIZE=3D2>Phone +1 212 588-9133</FONT>

<BR><FONT SIZE=3D2>Fax&nbsp;&nbsp; +1 212 588-9134</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://qosient.com">http://qosient.com</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: owner-rtfm@auckland.ac.nz [<A =
HREF=3D"mailto:owner-rtfm@auckland.ac.nz">mailto:owner-rtfm@auckland.ac.n=
z</A>]On</FONT>

<BR><FONT SIZE=3D2>&gt; Behalf Of Nevil Brownlee</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Sunday, April 15, 2001 4:26 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: rtfm@auckland.ac.nz</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Standard Flows: Next Move</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Hello All:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Here's my attempt to summarise the Mailing List =
Discussion so far:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Definition of 'flows'</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Collection of TCP or UDP microflows =
that </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - are forwarded along the same =
common path</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; - share the same class of =
service</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; or</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; Unidirectional series of IP packets =
of a given protocol,</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; with the same IP Address / Port =
endpoints, i.e. a 5-tuple.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; 'Common path' is a vague concept (except for a =
MPLS LSP).</FONT>

<BR><FONT SIZE=3D2>&gt; 'Class of service' is also vague (but we could =
use DSCodepoint).</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Include interface numbers?&nbsp; Would help with =
multicast.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Better not to, should stick with data which can =
be extracted </FONT>

<BR><FONT SIZE=3D2>&gt; directly from packets.&nbsp; Interfaces can't =
(an input interface</FONT>

<BR><FONT SIZE=3D2>&gt; may not know what the output interface will be), =
nor can</FONT>

<BR><FONT SIZE=3D2>&gt; AS numbers.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Better to have a minimum 'flow key.'&nbsp; Could =
allow for more</FONT>

<BR><FONT SIZE=3D2>&gt; data (interface numbers, ASNs, LSPs, etc.) as =
options.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Could be useful to keep 'flow definition' =
separate from</FONT>

<BR><FONT SIZE=3D2>&gt; 'flow identification,' e.g. use 5-tuple as =
definition,</FONT>

<BR><FONT SIZE=3D2>&gt; other attributes (IPv6 flow label, FlowID, =
ifIndex, ...)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; We need to start working on 'Requirements' =
...</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-------------------------------------</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I think it's time we started on a draft charter, =
and of course</FONT>

<BR><FONT SIZE=3D2>&gt; we need one or two Internet Drafts to support a =
BOF request.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Here's my attempt at a draft WG charter:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; IP Flow Export (IFX)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; At present there are three public-domain methods =
in use for </FONT>

<BR><FONT SIZE=3D2>&gt; collecting flow data:</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; - Netflow (on Cisco routers)</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; - LFAP (on Riverstone routers)</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; - RTFM (using NeTraMet on Unix =
boxes)</FONT>

<BR><FONT SIZE=3D2>&gt; Flow data is most commonly required for usage =
measurement, i.e. it</FONT>

<BR><FONT SIZE=3D2>&gt; is seen as a major component of Accounting, the =
third A in AAA.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Several router vendors have expressed strong =
support for a WG</FONT>

<BR><FONT SIZE=3D2>&gt; to develop a standard method of exporting flow =
data from routers.</FONT>

<BR><FONT SIZE=3D2>&gt; A preliminary meeting was held at the =
Minneapolis IETF meeting</FONT>

<BR><FONT SIZE=3D2>&gt; in March, and vigorous discussion has begun on =
the RTFM mailing</FONT>

<BR><FONT SIZE=3D2>&gt; list.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; We believe that the proposed Working Group would =
fall most naturally</FONT>

<BR><FONT SIZE=3D2>&gt; within the Operations and Management Area.&nbsp; =
Its goals and requirements</FONT>

<BR><FONT SIZE=3D2>&gt; are straightforward; the Group should be able to =
complete its work</FONT>

<BR><FONT SIZE=3D2>&gt; in about one year.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Goals:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 1. Produce a 'requirements' =
document.&nbsp; This will identify the</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; target community for =
SFX, expected uses of flow data,</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; and the constraints =
(reliability, timeliness, level of</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; detail, etc.) these uses =
imply.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 2. Define 'IP accounting flow,' and a data =
model for it.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 3. Specify mechanism(s) for exporting =
accounting flows.</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; These must allow for =
push and pull models, and be capable</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; of handling high volumes =
of flow data.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 4. Develop methods of configuring and =
controlling flow export</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; in a network =
device.&nbsp; For example,</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a. How =
much detail is required (level of aggregation)?</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b. =
Will data be read by the accounting system (pull model)?</FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c. Or =
should data be sent to the accounting system at</FONT>

<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 specified intervals (push model)?</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Milestones:</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 1. IP Flow Export Requirements =
(Informational RFC)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 2. IP Flow Definition and Export Control =
Mechanisms </FONT>

<BR><FONT SIZE=3D2>&gt; (Standards Track RFC)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt;&nbsp; 3. Flow Export: Transport Mechanisms =
(Informational RFC)</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Is this on the right lines?&nbsp; What have I =
left out?&nbsp; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; I think we need an initial version of the =
Requirements draft, as soon</FONT>

<BR><FONT SIZE=3D2>&gt; as we can manage to produce it.&nbsp; I'll be =
away from email for much of</FONT>

<BR><FONT SIZE=3D2>&gt; the next three weeks, but after that I'll be =
able to put some effort</FONT>

<BR><FONT SIZE=3D2>&gt; into editing such a draft.&nbsp; So, =
comments/suggestions please ...</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; Cheers, Nevil</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; =
+-------------------------------------------------------------</FONT>

<BR><FONT SIZE=3D2>&gt; --------+</FONT>

<BR><FONT SIZE=3D2>&gt; | Nevil =
Brownlee&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Director, =
Technology </FONT>

<BR><FONT SIZE=3D2>&gt; Development |</FONT>

<BR><FONT SIZE=3D2>&gt; | Phone: +64 9 373 7599 =
x8941&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ITSS, The University of =
</FONT>

<BR><FONT SIZE=3D2>&gt; Auckland |</FONT>

<BR><FONT SIZE=3D2>&gt; |&nbsp;&nbsp; FAX: +64 9 373 =
7021&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Private Bag 92019, Auckland, New =
</FONT>

<BR><FONT SIZE=3D2>&gt; Zealand |</FONT>

<BR><FONT SIZE=3D2>&gt; =
+-------------------------------------------------------------</FONT>

<BR><FONT SIZE=3D2>&gt; --------N</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0031_01C0CC0E.C6E68B20--



From owner-rtfm@auckland.ac.nz  Mon Apr 23 20:20:26 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15113
	for <rtfm-archive@odin.ietf.org>; Mon, 23 Apr 2001 20:20:24 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id KAA10279;
	Tue, 24 Apr 2001 10:26:07 +1200 (NZST)
Received: from smtp9ve.mailsrvcs.net ([206.46.170.141])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA10266;
	Tue, 24 Apr 2001 10:26:02 +1200 (NZST)
Received: from sphynx (adsl-151-202-199-44.nyc.adsl.bellatlantic.net [151.202.199.44])
	by smtp9ve.mailsrvcs.net (8.9.1/8.9.1) with SMTP id RAA11152;
	Mon, 23 Apr 2001 17:25:41 -0500 (CDT)
Reply-To: <carter@qosient.com>
From: "Carter Bullard" <carter@qosient.com>
To: <plonka@doit.wisc.edu>, "'Nevil Brownlee'" <n.brownlee@auckland.ac.nz>
Cc: <rtfm@auckland.ac.nz>
Subject: RE: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next Move")
Date: Mon, 23 Apr 2001 18:25:22 -0400
Message-ID: <38E99DA2CEFA7248B5828BBF99344D86CBE6@ptah.newyork.qosient.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0039_01C0CC22.C3115020"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20010423112822.A22844@doit.wisc.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0039_01C0CC22.C3115020
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hey Guys,
> 
> What prior work defines "microflows"?  (For the moment I'm presuming
> for TCP that that would be a fragment of a stream.)

My experience has been that people who talk about microflows
are generally backbone oriented.  For these "big pipe" minded folk,
aggregated flows such as AS-to-AS, or Net-to-Net flows,
are "flows", and the traditional 5-tuple flow is a microflow.

I think the draft is using this perspective.

I'm one to think that if you have microflows, you should have
flows and macroflows.  I put the flow at the Type-P level, which
includes the 5-tuple flow.  In this view, AS-to-AS, or Net-to-Net,
flows would be macroflows, and sub-transactions within a Type-P
flow would be a microflow.  This tracks the concepts in
RMON pretty well, such that RMON link stats are macroflow stats,
RMON2 gives you flow stats, and newer technology, such as APM,
give you microflow measures.


Carter

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

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

------=_NextPart_000_0039_01C0CC22.C3115020
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: WG name: &quot;IPFX&quot;?, etc. (was &quot;Re: Standard =
Flows: Next Move&quot;)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hey Guys,</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; What prior work defines =
&quot;microflows&quot;?&nbsp; (For the moment I'm presuming</FONT>

<BR><FONT SIZE=3D2>&gt; for TCP that that would be a fragment of a =
stream.)</FONT>
</P>

<P><FONT SIZE=3D2>My experience has been that people who talk about =
microflows</FONT>

<BR><FONT SIZE=3D2>are generally backbone oriented.&nbsp; For these =
&quot;big pipe&quot; minded folk,</FONT>

<BR><FONT SIZE=3D2>aggregated flows such as AS-to-AS, or Net-to-Net =
flows,</FONT>

<BR><FONT SIZE=3D2>are &quot;flows&quot;, and the traditional 5-tuple =
flow is a microflow.</FONT>
</P>

<P><FONT SIZE=3D2>I think the draft is using this perspective.</FONT>
</P>

<P><FONT SIZE=3D2>I'm one to think that if you have microflows, you =
should have</FONT>

<BR><FONT SIZE=3D2>flows and macroflows.&nbsp; I put the flow at the =
Type-P level, which</FONT>

<BR><FONT SIZE=3D2>includes the 5-tuple flow.&nbsp; In this view, =
AS-to-AS, or Net-to-Net,</FONT>

<BR><FONT SIZE=3D2>flows would be macroflows, and sub-transactions =
within a Type-P</FONT>

<BR><FONT SIZE=3D2>flow would be a microflow.&nbsp; This tracks the =
concepts in</FONT>

<BR><FONT SIZE=3D2>RMON pretty well, such that RMON link stats are =
macroflow stats,</FONT>

<BR><FONT SIZE=3D2>RMON2 gives you flow stats, and newer technology, =
such as APM,</FONT>

<BR><FONT SIZE=3D2>give you microflow measures.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Carter</FONT>
</P>

<P><FONT SIZE=3D2>Carter Bullard</FONT>

<BR><FONT SIZE=3D2>QoSient, LLC</FONT>

<BR><FONT SIZE=3D2>300 E. 56th Street, Suite 18K</FONT>

<BR><FONT SIZE=3D2>New York, New York&nbsp; 10022</FONT>
</P>

<P><FONT SIZE=3D2>carter@qosient.com</FONT>

<BR><FONT SIZE=3D2>Phone +1 212 588-9133</FONT>

<BR><FONT SIZE=3D2>Fax&nbsp;&nbsp; +1 212 588-9134</FONT>

<BR><FONT SIZE=3D2><A =
HREF=3D"http://qosient.com">http://qosient.com</A></FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_0039_01C0CC22.C3115020--



From owner-rtfm@auckland.ac.nz  Tue Apr 24 05:49:55 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05437
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 05:49:53 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id RAA16847;
	Tue, 24 Apr 2001 17:19:57 +1200 (NZST)
Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id RAA16814;
	Tue, 24 Apr 2001 17:19:49 +1200 (NZST)
Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago)
	id WAA24905; Mon, 23 Apr 2001 22:19:18 -0700 (PDT)
Received: from celtic.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4)
	id WAA26995; Mon, 23 Apr 2001 22:19:17 -0700
Message-Id: <5.0.2.1.1.20010424060857.02f1aec0@mordor>
X-Sender: mrm@mordor
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 24 Apr 2001 06:19:44 -0700
To: plonka@doit.wisc.edu, Nevil Brownlee <n.brownlee@auckland.ac.nz>
From: Mike MacFaden <mrm@riverstonenet.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next
  Move")
Cc: rtfm@auckland.ac.nz
In-Reply-To: <20010423112822.A22844@doit.wisc.edu>
References: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

At 11:28 AM 4/23/01 -0500, Dave Plonka wrote:
>On Sun, Apr 15, 2001 at 01:26:29AM -0700, Nevil Brownlee wrote:
>> 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)
>
>I would prefer "IPFX" to either "IFX" or "SFX".  We should settle on
>this ASAP since it is a prerequisite for the BoF prerequisites ;^).

Since IETF is about IP, I agree that IP should be the key thing we 
want to express. And from what I can see for existing practice, 
what folks want to export anyway.


>> 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.
>
>Is it relevent to mention that other vendors such as Juniper and
>Extreme have adopted the Cisco-defined NetFlow export PDU?

This section will be dropped from the charter per AD request.
Suffice it to say that what we are going to standardize is
based on de facto standards not unlike the efforts of
the Secure Shell working group:
http://www.ietf.org/html.charters/secsh-charter.html

It will be very important not to step on existing proprietary
technology and I urge anyone to speak up and issue any assertions
in a timely fahsion should we cross over into ones Intellectual Property.

>Presumably this is to acheive compatibility with flow collectors, but
>since NetFlow is not an Official Standard Protocol, various
>implementations do not necessarily use the same flow definition and
>therefore do not ensure interoperability of collected accounting data.
>
>I see this as a prime motivating factor for doing this WG _now_.

Exactly. 

It is my opinion that we are standardizing known technology
and not inventing something new hence any working group created
should be able to complete the tasks set forth in less than a year.

Regards,
Mike MacFaden



From owner-rtfm@auckland.ac.nz  Tue Apr 24 11:10:34 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09021
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 11:10:32 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id BAA11329;
	Wed, 25 Apr 2001 01:01:54 +1200 (NZST)
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 BAA11321;
	Wed, 25 Apr 2001 01:01:46 +1200 (NZST)
From: quittek@ccrle.nec.de
Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1])
	by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id f3OD2ke94878;
	Tue, 24 Apr 2001 15:02:46 +0200 (CEST)
Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30)
	id 07B77C054; Tue, 24 Apr 2001 16:09:12 +0200 (CEST)
To: Mike MacFaden <mrm@riverstonenet.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next  Move")
Message-ID: <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de>
Date: Tue, 24 Apr 2001 16:09:11 +0200 (CEST)
Cc: plonka@doit.wisc.edu, Nevil Brownlee <n.brownlee@auckland.ac.nz>,
        rtfm@auckland.ac.nz
References: <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz> <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz> <5.0.2.1.1.20010424060857.02f1aec0@mordor>
In-Reply-To: <5.0.2.1.1.20010424060857.02f1aec0@mordor>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
X-Originating-IP: 192.168.102.83
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Mike,

Mike MacFaden <mrm@riverstonenet.com> wrote:
> 
 [...]
> >
> >Is it relevent to mention that other vendors such as Juniper and
> >Extreme have adopted the Cisco-defined NetFlow export PDU?
> 
> This section will be dropped from the charter per AD request.

Are there more requests for changes from the ADs?
It would be nice to see them on this list.

    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



From owner-rtfm@auckland.ac.nz  Tue Apr 24 11:40:03 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09439
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 11:40:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id UAA23018;
	Tue, 24 Apr 2001 20:40:12 +1200 (NZST)
Received: from avalon.netcom.net.uk (avalon.netcom.net.uk [194.42.225.7])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id UAA22991
	for <rtfm@auckland.ac.nz>; Tue, 24 Apr 2001 20:40:03 +1200 (NZST)
Received: from consol.netcomuk.co.uk ([194.42.248.30] helo=exchange.consol.co.uk)
	by avalon.netcom.net.uk with esmtp (Exim 3.20 #3)
	id 14ryMU-0006qO-00; Tue, 24 Apr 2001 09:39:54 +0100
Received: by EXCHANGE with Internet Mail Service (5.0.1460.8)
	id <2VKPG71F>; Tue, 24 Apr 2001 09:35:25 +0100
Message-ID: <CCE353CEDF5AD31187A50090279CC74D0184D983@EXCHANGE>
From: Mark <Mark@consol.co.uk>
To: carter@qosient.com, rtfm@auckland.ac.nz
Subject: UNSUBS
Date: Tue, 24 Apr 2001 09:35:24 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: multipart/alternative;
	boundary="---- =_NextPart_001_01C0CC99.8218B4F6"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01C0CC99.8218B4F6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

please unsubscribe me from this list

thank you

mark crompton
creative director
consolidated communications
london
020 7208 2749

	-----Original Message-----
	From:	Carter Bullard [SMTP:carter@qosient.com]
	Sent:	Monday, April 23, 2001 9:02 PM
	To:	rtfm@auckland.ac.nz
	Subject:	RE: Standard Flows: Next Move


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

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

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

	Carter=20

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

	carter@qosient.com=20
	Phone +1 212 588-9133=20
	Fax=A0=A0 +1 212 588-9134=20
	http://qosient.com <http://qosient.com> =20


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

	>=20
	> Definition of 'flows'=20
	>=20
	>=A0=A0 Collection of TCP or UDP microflows that=20
	>=A0=A0 - are forwarded along the same common path=20
	>=A0=A0 - share the same class of service=20
	>=20
	> or=20
	>=A0=A0 Unidirectional series of IP packets of a given protocol,=20
	>=A0=A0 with the same IP Address / Port endpoints, i.e. a 5-tuple.=20
	>=20
	> 'Common path' is a vague concept (except for a MPLS LSP).=20
	> 'Class of service' is also vague (but we could use DSCodepoint).=20
	>=20
	> Include interface numbers?=A0 Would help with multicast.=20
	>=20
	> Better not to, should stick with data which can be extracted=20
	> directly from packets.=A0 Interfaces can't (an input interface=20
	> may not know what the output interface will be), nor can=20
	> AS numbers.=20
	>=20
	> Better to have a minimum 'flow key.'=A0 Could allow for more=20
	> data (interface numbers, ASNs, LSPs, etc.) as options.=20
	>=20
	> Could be useful to keep 'flow definition' separate from=20
	> 'flow identification,' e.g. use 5-tuple as definition,=20
	> other attributes (IPv6 flow label, FlowID, ifIndex, ...)=20
	>=20
	> We need to start working on 'Requirements' ...=20
	>=20
	>=A0=A0=A0=A0=A0=A0=A0=A0 -------------------------------------=20
	>=20
	>=20
	> I think it's time we started on a draft charter, and of course=20
	> we need one or two Internet Drafts to support a BOF request.=20
	>=20
	> Here's my attempt at a draft WG charter:=20
	>=20
	>=20
	> IP Flow Export (IFX)=20
	>=20
	> At present there are three public-domain methods in use for=20
	> collecting flow data:=20
	>=A0 - Netflow (on Cisco routers)=20
	>=A0 - LFAP (on Riverstone routers)=20
	>=A0 - RTFM (using NeTraMet on Unix boxes)=20
	> 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.=20
	>=20
	> Several router vendors have expressed strong support for a WG=20
	> to develop a standard method of exporting flow data from routers.=20
	> A preliminary meeting was held at the Minneapolis IETF meeting=20
	> in March, and vigorous discussion has begun on the RTFM mailing=20
	> list.=20
	>=20
	> We believe that the proposed Working Group would fall most
naturally=20
	> within the Operations and Management Area.=A0 Its goals and
requirements=20
	> are straightforward; the Group should be able to complete its work

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

	>=A0=A0=A0=A0=A0=A0=A0 c. Or should data be sent to the accounting =
system at=20
	>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 specified intervals (push model)?=20
	>=20
	> Milestones:=20
	>=20
	>=A0 1. IP Flow Export Requirements (Informational RFC)=20
	>=20
	>=A0 2. IP Flow Definition and Export Control Mechanisms=20
	> (Standards Track RFC)=20
	>=20
	>=A0 3. Flow Export: Transport Mechanisms (Informational RFC)=20
	>=20
	>=20
	> Is this on the right lines?=A0 What have I left out?=A0=20
	>=20
	> I think we need an initial version of the Requirements draft, as
soon=20
	> as we can manage to produce it.=A0 I'll be away from email for much
of=20
	> the next three weeks, but after that I'll be able to put some
effort=20
	> into editing such a draft.=A0 So, comments/suggestions please ...=20
	>=20
	> Cheers, Nevil=20
	>=20
	> +-------------------------------------------------------------=20
	> --------+=20
	> | Nevil =
Brownlee=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Director, Technology=20
	> Development |=20
	> | Phone: +64 9 373 7599 x8941=A0=A0=A0=A0=A0=A0=A0 ITSS, The =
University of=20
	> Auckland |=20
	> |=A0=A0 FAX: +64 9 373 7021=A0=A0=A0=A0=A0 Private Bag 92019, =
Auckland, New=20
	> Zealand |=20
	> +-------------------------------------------------------------=20
	> --------N=20
	>=20
	>=20
	>=20
=09

------ =_NextPart_001_01C0CC99.8218B4F6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1460.9">
<TITLE>UNSUBS</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">please unsubscribe me from =
this list</FONT>
</P>

<P><FONT COLOR=3D"#000000" FACE=3D"Arial">thank you</FONT>
</P>

<P><FONT COLOR=3D"#808080" FACE=3D"Arial">mark crompton</FONT>
<BR><FONT COLOR=3D"#808080" FACE=3D"Arial">creative director</FONT>
<BR><FONT COLOR=3D"#808080" FACE=3D"Arial">consolidated =
communications</FONT>
<BR><FONT COLOR=3D"#808080" FACE=3D"Arial">london</FONT>
<BR><FONT COLOR=3D"#808080" FACE=3D"Arial">020 7208 2749</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT FACE=3D"Arial">From:&nbsp;&nbsp; Carter Bullard =
[SMTP:carter@qosient.com]</FONT></B>
<BR><B><FONT FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
FACE=3D"Arial">Monday, April 23, 2001 9:02 PM</FONT>
<BR><B><FONT FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT FACE=3D"Arial">rtfm@auckland.ac.nz</FONT>
<BR><B><FONT =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT FACE=3D"Arial">RE: Standard Flows: Next Move</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Hey =
Nevil,</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Sorry for the =
late reply.=A0 I've been away.</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">This is a great =
start for this project!=A0 I agree</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">with Dave that =
IPFX would be a great name.=A0</FONT>=20
</P>

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

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Argus can read =
Netflow, convert it and redistribute it, if</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">that helps =
;o)</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Carter</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Carter =
Bullard</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">QoSient, =
LLC</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">300 E. 56th =
Street, Suite 18K</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">New York, New =
York=A0 10022</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"> </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">carter@qosient.com</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Phone +1 212 =
588-9133</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Fax=A0=A0 +1 212 =
588-9134</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><A HREF=3D"http://qosient.com"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">http://qosient.com</FONT></U></A><FONT =
COLOR=3D"#000000" FACE=3D"Arial"> </FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; -----Original =
Message-----</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; From: =
owner-rtfm@auckland.ac.nz [</FONT> <A =
HREF=3D"mailto:owner-rtfm@auckland.ac.nz"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 =
FACE=3D"Arial">mailto:owner-rtfm@auckland.ac.nz</FONT></U></A><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">]On</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Behalf Of =
Nevil Brownlee</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Sent: =
Sunday, April 15, 2001 4:26 AM</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; To: =
rtfm@auckland.ac.nz</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Subject: =
Standard Flows: Next Move</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Hello =
All:</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Here's my attempt =
to summarise the Mailing List Discussion so far:</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Definition of =
'flows'</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0 Collection =
of TCP or UDP microflows that</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0 - are =
forwarded along the same common path</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0 - =
share the same class of service</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; or</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0 =
Unidirectional series of IP packets of a given protocol,</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0 with =
the same IP Address / Port endpoints, i.e. a 5-tuple.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 'Common path' is a =
vague concept (except for a MPLS LSP).</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 'Class of =
service' is also vague (but we could use DSCodepoint).</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Include interface =
numbers?=A0 Would help with multicast.</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Better not to, =
should stick with data which can be extracted</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; directly from =
packets.=A0 Interfaces can't (an input interface</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; may not =
know what the output interface will be), nor can</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; AS =
numbers.</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Better to have a =
minimum 'flow key.'=A0 Could allow for more</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; data =
(interface numbers, ASNs, LSPs, etc.) as options.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Could be useful to =
keep 'flow definition' separate from</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 'flow =
identification,' e.g. use 5-tuple as definition,</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; other =
attributes (IPv6 flow label, FlowID, ifIndex, ...)</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; We need to start =
working on 'Requirements' ...</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0=A0 =
-------------------------------------</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; I think it's time =
we started on a draft charter, and of course</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; we need one =
or two Internet Drafts to support a BOF request.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Here's my attempt =
at a draft WG charter:</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; IP Flow Export =
(IFX)</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; At present there =
are three public-domain methods in use for</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; collecting flow =
data:</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 - =
Netflow (on Cisco routers)</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 - LFAP =
(on Riverstone routers)</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 - RTFM =
(using NeTraMet on Unix boxes)</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Flow data =
is most commonly required for usage measurement, i.e. it</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; is seen as =
a major component of Accounting, the third A in AAA.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Several router =
vendors have expressed strong support for a WG</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; to develop =
a standard method of exporting flow data from routers.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; A =
preliminary meeting was held at the Minneapolis IETF =
meeting</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; in March, =
and vigorous discussion has begun on the RTFM mailing</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
list.</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; We believe that =
the proposed Working Group would fall most naturally</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; within the =
Operations and Management Area.=A0 Its goals and =
requirements</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; are =
straightforward; the Group should be able to complete its =
work</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; in about =
one year.</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Goals:</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 1. Produce a =
'requirements' document.=A0 This will identify the</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
target community for SFX, expected uses of flow data,</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
and the constraints (reliability, timeliness, level of</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
detail, etc.) these uses imply.</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 2. Define 'IP =
accounting flow,' and a data model for it.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 3. Specify =
mechanism(s) for exporting accounting flows.</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
These must allow for push and pull models, and be capable</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
of handling high volumes of flow data.</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 4. Develop =
methods of configuring and controlling flow export</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0=A0=A0=A0 =
in a network device.=A0 For example,</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0 a. How much detail is required =
(level of aggregation)?</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0 b. Will data be read by the =
accounting system (pull model)?</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0 c. Or should data be sent to =
the accounting system at</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">&gt;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 specified intervals =
(push model)?</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
Milestones:</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 1. IP Flow =
Export Requirements (Informational RFC)</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 2. IP Flow =
Definition and Export Control Mechanisms</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; (Standards Track =
RFC)</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;=A0 3. Flow Export: =
Transport Mechanisms (Informational RFC)</FONT><FONT COLOR=3D"#000000" =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Is this on the =
right lines?=A0 What have I left out?=A0</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; I think we need an =
initial version of the Requirements draft, as soon</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; as we can =
manage to produce it.=A0 I'll be away from email for much =
of</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; the next =
three weeks, but after that I'll be able to put some effort</FONT><FONT =
COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; into =
editing such a draft.=A0 So, comments/suggestions please =
...</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Cheers, =
Nevil</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
+-------------------------------------------------------------</FONT><FO=
NT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
--------+</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; | Nevil =
Brownlee=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Director, Technology</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Development =
|</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; | Phone: =
+64 9 373 7599 x8941=A0=A0=A0=A0=A0=A0=A0 ITSS, The University =
of</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Auckland =
|</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; |=A0=A0 =
FAX: +64 9 373 7021=A0=A0=A0=A0=A0 Private Bag 92019, Auckland, =
New</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Zealand =
|</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
+-------------------------------------------------------------</FONT><FO=
NT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; =
--------N</FONT><FONT COLOR=3D"#000000" FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>=20
<BR>
</P>
</UL>
</BODY>
</HTML>
------ =_NextPart_001_01C0CC99.8218B4F6--


From owner-rtfm@auckland.ac.nz  Tue Apr 24 12:39:43 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10334
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 12:39:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA16931;
	Wed, 25 Apr 2001 02:12:11 +1200 (NZST)
Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id CAA16921;
	Wed, 25 Apr 2001 02:12:08 +1200 (NZST)
Received: from kshah-w2k.cisco.com (biking-dsl1.cisco.com [10.21.129.82])
	by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA16443;
	Tue, 24 Apr 2001 10:11:14 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010424100953.01c277d0@rooster.cisco.com>
X-Sender: kshah@rooster.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Apr 2001 10:11:09 -0400
To: quittek@ccrle.nec.de, Mike MacFaden <mrm@riverstonenet.com>
From: Kamlesh Shah <kshah@cisco.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next 
  Move")
Cc: plonka@doit.wisc.edu, Nevil Brownlee <n.brownlee@auckland.ac.nz>,
        rtfm@auckland.ac.nz
In-Reply-To: <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de>
References: <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

Folks,

I am just joining the discussions. So pardon my ignorence..

What is AD ?

Also, can someone email me the location of current proposal of this group ?

PS: I have worked extensively on Cisco's NetFlow.

Regards.

At 04:09 PM 4/24/2001 +0200, quittek@ccrle.nec.de wrote:
>Hi Mike,
>
>Mike MacFaden <mrm@riverstonenet.com> wrote:
>> 
> [...]
>> >
>> >Is it relevent to mention that other vendors such as Juniper and
>> >Extreme have adopted the Cisco-defined NetFlow export PDU?
>> 
>> This section will be dropped from the charter per AD request.
>
>Are there more requests for changes from the ADs?
>It would be nice to see them on this list.
>
>    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 

((((((((((((())))))))))))
Kamlesh Shah  CCIE # 2803
Technical Marketing Engineer - MPLS, ISBU



From owner-rtfm@auckland.ac.nz  Tue Apr 24 13:54:02 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11417
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 13:54:01 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id DAA27472;
	Wed, 25 Apr 2001 03:58:45 +1200 (NZST)
Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id DAA27463;
	Wed, 25 Apr 2001 03:58:43 +1200 (NZST)
Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago)
	id IAA19945; Tue, 24 Apr 2001 08:58:09 -0700 (PDT)
Received: from celtic.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4)
	id IAA27313; Tue, 24 Apr 2001 08:58:07 -0700
Message-Id: <5.0.2.1.1.20010424163532.02f130d0@mordor>
X-Sender: mrm@mordor
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 24 Apr 2001 16:59:02 -0700
To: quittek@ccrle.nec.de
From: Mike MacFaden <mrm@riverstonenet.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next 
  Move")
Cc: plonka@doit.wisc.edu, Nevil Brownlee <n.brownlee@auckland.ac.nz>,
        rtfm@auckland.ac.nz
In-Reply-To: <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de>
References: <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

At 04:09 PM 4/24/01 +0200, quittek@ccrle.nec.de wrote:
>Are there more requests for changes from the ADs?
>It would be nice to see them on this list.

Indeed. This is my understanding of what the
ADs want to see happen:

1) Must involve experienced users in this effort
2) Must discuss the data format, protocol
   protocol by which devices export flow data,
   and how flow data consumers 
   control what they wish to have measured and to receive
3) Must clearly describe the problem being solved
4) Must create a new single purpose mailing list 
   and start working on the charter

Status:

Dave Plonka is currently setting up a new list 
and Nevil has asked me to publish a revised 
charter to that list for continued
discussion and revision. If folks want to continue
discussing on this list for now, that is fine too.

Regards,
Mike



From owner-rtfm@auckland.ac.nz  Tue Apr 24 17:33:24 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15786
	for <rtfm-archive@odin.ietf.org>; Tue, 24 Apr 2001 17:33:23 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA29817;
	Wed, 25 Apr 2001 07:58:17 +1200 (NZST)
Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA29804
	for <rtfm@auckland.ac.nz>; Wed, 25 Apr 2001 07:58:13 +1200 (NZST)
Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 14s8wK-0007XX-00; Tue, 24 Apr 2001 14:57:36 -0500
Date: Tue, 24 Apr 2001 14:57:36 -0500
From: Dave Plonka <plonka@doit.wisc.edu>
To: rtfm@auckland.ac.nz
Cc: ipfx@net.doit.wisc.edu
Subject: new IPFX mailing list and archive
Message-ID: <20010424145736.A28346@doit.wisc.edu>
Reply-To: plonka@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Organization: UW-Madison, DoIT, Network Services
X-VMS-Error: %SYSTEM-F-NODOMAIN, resource domain not found
X-Shakespearean-Insult: Thou puny bat-fowling clack-dish
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk


RTFM list members,

The following is a general announcement of the new mailing list and web
archive for our Internet Protocol Flow eXport (IPFX) effort.

If you wish to participate in the IPFX effor please join the "ipfx"
mailing list and continue the discussion there.  (See subscription
instructions below.)

I have also created a web site to host the mailing list archive:

   http://net.doit.wisc.edu/ipfx/

which will soon also be known as "http://ipfx.doit.wisc.edu".
If you would like to use this site for other IPFX content, feel free to
contact me.

Dave

----------------------------------------------------------------------

 NAME
    `IPFX' - Internet Protocol Flow eXport

 DESCRIPTION
    Internet Protocol Flow eXport (IPFX) is an effort to standardize
    flow export.

 Mailing List
    The `IPFX' mailing list is a list for discussion about
    standardizing "Internet Protocol Flow eXport" (IPFX). This list
    is hosted by the Division of Information Technology's Network
    Services group at the University of Wisconsin - Madison.

    Once subscribed (see below), you can post to the list by
    directing email to:

       ipfx@net.doit.wisc.edu

    To subscribe, send email to:

       majordomo@net.doit.wisc.edu

    containing:

       subscribe ipfx

    Subsequently, you should receive an automatic response that will
    request that you verify your request to become a member of the
    list, to which you must reply with the authentication
    information there-in. Then, in response to your reply, you
    should receive a welcome message. If you have any questions
    about the administrative policies of this list's manager, please
    contact:

       owner-ipfx@net.doit.wisc.edu

 Mailing List Archives
    The list archive is available at:

       http://net.doit.wisc.edu/ipfx/list/

 IPFX Resources
       http://www.ietf.org/
       http://www.ietf.org/html.charters/aaa-charter.html

-- 
plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI


From owner-rtfm@auckland.ac.nz  Wed Apr 25 18:52:46 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03366
	for <rtfm-archive@odin.ietf.org>; Wed, 25 Apr 2001 18:52:44 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA14804;
	Thu, 26 Apr 2001 07:45:28 +1200 (NZST)
Received: from buddha.automagic.org (IDENT:qmailr@buddha-nexxia.automagic.org [207.61.141.34])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id HAA14793
	for <rtfm@auckland.ac.nz>; Thu, 26 Apr 2001 07:45:25 +1200 (NZST)
Received: (qmail 27753 invoked by uid 100); 25 Apr 2001 19:45:21 -0000
Date: Wed, 25 Apr 2001 15:45:21 -0400
From: Joe Abley <jabley-ietf@automagic.org>
To: Mike MacFaden <mrm@riverstonenet.com>
Cc: quittek@ccrle.nec.de, plonka@doit.wisc.edu,
        Nevil Brownlee <n.brownlee@auckland.ac.nz>, rtfm@auckland.ac.nz
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next Move")
Message-ID: <20010425154521.N19145@buddha.home.automagic.org>
References: <5.0.2.1.1.20010424060857.02f1aec0@mordor> <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz> <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz> <5.0.2.1.1.20010424060857.02f1aec0@mordor> <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de> <5.0.2.1.1.20010424163532.02f130d0@mordor>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.2.1.1.20010424163532.02f130d0@mordor>; from mrm@riverstonenet.com on Tue, Apr 24, 2001 at 04:59:02PM -0700
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

On Tue, Apr 24, 2001 at 04:59:02PM -0700, Mike MacFaden wrote:
> At 04:09 PM 4/24/01 +0200, quittek@ccrle.nec.de wrote:
> >Are there more requests for changes from the ADs?
> >It would be nice to see them on this list.
> 
> Indeed. This is my understanding of what the
> ADs want to see happen:
> 
> 1) Must involve experienced users in this effort

Does this mean vendors who have experience in implementing support
for flow export, or operators who have experience in using it?


Joe


From owner-rtfm@auckland.ac.nz  Wed Apr 25 21:59:20 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06749
	for <rtfm-archive@odin.ietf.org>; Wed, 25 Apr 2001 21:59:18 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id LAA08135;
	Thu, 26 Apr 2001 11:06:55 +1200 (NZST)
Received: from rooster.cisco.com (rooster.cisco.com [64.102.19.200])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id LAA08072;
	Thu, 26 Apr 2001 11:06:41 +1200 (NZST)
Received: from kshah-w2k.cisco.com (dhcp-1sjc13-2-83-48.cisco.com [171.70.83.48])
	by rooster.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA16320;
	Wed, 25 Apr 2001 19:05:54 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010425190454.01c61ee8@rooster.cisco.com>
X-Sender: kshah@rooster.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Apr 2001 19:05:38 -0700
To: Joe Abley <jabley-ietf@automagic.org>,
        Mike MacFaden <mrm@riverstonenet.com>
From: Kamlesh Shah <kshah@cisco.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next
  Move")
Cc: quittek@ccrle.nec.de, plonka@doit.wisc.edu,
        Nevil Brownlee <n.brownlee@auckland.ac.nz>, rtfm@auckland.ac.nz
In-Reply-To: <20010425154521.N19145@buddha.home.automagic.org>
References: <5.0.2.1.1.20010424163532.02f130d0@mordor>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de>
 <5.0.2.1.1.20010424163532.02f130d0@mordor>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

Wouldn't it make sense to have some representation from both camps ?

The only catch is to hope that the right folks are talking (or we are talking to the right folks).. 

At 03:45 PM 4/25/2001 -0400, Joe Abley wrote:
>On Tue, Apr 24, 2001 at 04:59:02PM -0700, Mike MacFaden wrote:
>> At 04:09 PM 4/24/01 +0200, quittek@ccrle.nec.de wrote:
>> >Are there more requests for changes from the ADs?
>> >It would be nice to see them on this list.
>> 
>> Indeed. This is my understanding of what the
>> ADs want to see happen:
>> 
>> 1) Must involve experienced users in this effort
>
>Does this mean vendors who have experience in implementing support
>for flow export, or operators who have experience in using it?
>
>
>Joe 

((((((((((((())))))))))))
Kamlesh Shah  CCIE # 2803
Technical Marketing Engineer - MPLS, ISBU



From owner-rtfm@auckland.ac.nz  Thu Apr 26 03:12:43 2001
Received: from mailhost.auckland.ac.nz ([130.216.1.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA25175
	for <rtfm-archive@odin.ietf.org>; Thu, 26 Apr 2001 03:12:42 -0400 (EDT)
Received: (from majordom@localhost)
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id RAA08579;
	Thu, 26 Apr 2001 17:36:16 +1200 (NZST)
Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10])
	by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id RAA08552;
	Thu, 26 Apr 2001 17:36:08 +1200 (NZST)
Received: from mordor.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago)
	id WAA21070; Wed, 25 Apr 2001 22:35:04 -0700 (PDT)
Received: from celtic.riverstonenet.com by mordor.yagosys.com (SMI-8.6/SMI-SVR4)
	id WAA13774; Wed, 25 Apr 2001 22:35:02 -0700
Message-Id: <5.0.2.1.1.20010426062719.034b9d00@mordor>
X-Sender: mrm@mordor
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 26 Apr 2001 06:36:01 -0700
To: Joe Abley <jabley-ietf@automagic.org>
From: Mike MacFaden <mrm@riverstonenet.com>
Subject: Re: WG name: "IPFX"?, etc. (was "Re: Standard Flows: Next
  Move")
Cc: quittek@ccrle.nec.de, plonka@doit.wisc.edu,
        Nevil Brownlee <n.brownlee@auckland.ac.nz>, rtfm@auckland.ac.nz,
        ipfx@net.doit.wisc.edu
In-Reply-To: <20010425154521.N19145@buddha.home.automagic.org>
References: <5.0.2.1.1.20010424163532.02f130d0@mordor>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <EXECMAIL.1010415012629.B591@nebbiolo.auckland.ac.nz>
 <5.0.2.1.1.20010424060857.02f1aec0@mordor>
 <988121351.3ae58907ece75@citadel.mobility.ccrle.nec.de>
 <5.0.2.1.1.20010424163532.02f130d0@mordor>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rtfm@auckland.ac.nz
Precedence: bulk

At 03:45 PM 4/25/01 -0400, Joe Abley wrote:
>On Tue, Apr 24, 2001 at 04:59:02PM -0700, Mike MacFaden wrote:
>> 1) Must involve experienced users in this effort
>
>Does this mean vendors who have experience in implementing support
>for flow export, or operators who have experience in using it?

The AD requested involving operators.

If you have not subscribed to ipfx mailing list, please
let's move all discussions there now, the list is archived.

http://net.doit.wisc.edu/ipfx/

Regards,
Mike