Subject: Re: DRAFT charter for proposed RTFM2 WG

From: Juergen Quittek <[email-masked]>
Date: Thu, 01 Feb 2001 18:42:07 +0100

I have some comments on the goals suggested in the charter.
I suggest to discuss the goals item by item.
For each item we may consider

  - What would be the resulting benefit?
  - Is it or does it appear to be technically feasible?
  - Is "now" the right time to work on this item?
  - Can we expect sufficient support by technical,
    experts, i.e. who is willing to contribute?
  - What would be the expected output documents?
  - What timeframe would be appropriate?
  - Is the IETF the right place for this item?

I'll send some followup messages starting a discussion on these
questions for each goal of the suggested charter. Please anyone
feel free to suggest further goals on this list.

    Juergen
-- 
Juergen Quittek     [email-masked]     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:
> 
> Back in December we held a well-attended BOF session at the San Diego
> IETF meeting.  Consensus of the meeting was that not only were there
> worthwhile things for a new Working Group to do, but there were people
> at the meeting who were preapred to do the work.
> 
> The BOF minutes (on the RTFM home page at
> www.auckland.ac.nz/net/Internet/rtfm) record our consensus that
> we should work on a draft charter on the RTFM email list.
> 
> I've been waiting for some guidance on a proposed charter from our Area
> Directors, but I see that scheduling is open now for the next IETF
> meeting in Minneapolis next March.  If we want a session there, we need
> to get moving.  To kick off discussion, I've attached a draft WG
> charter below.  Would you please read it, and:
> 
>  a) If you think the draft charter is badly worded, doesn't say
>     the right things, or leaves out things which you think are
>     important, send your comments to the list.
> 
>  b) If you (and/or your company) would be prepared to work on documents,
>     please, please send a note saying which ones either to the list,
>     or directly to me.
> 
> If a new WG is to be chartered, we need to demonstrate strong support
> for it, and well-defined goals.  Tell us what you think!
> 
> Cheers, Nevil
> 
> +---------------------------------------------------------------------+
> | Nevil Brownlee                     Director, Technology Development |
> | Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
> |   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
> +---------------------------------------------------------------------P
> 
>        Charter for a Proposed RTFM2 Working Group
> 
>            **** DRAFT **** Fri 15 Dec 00 ****
> 
> In October 1999 RFCs 2720-2724 were published, specifying the RTFM
> Traffic Measurement Architecture.  Since then many sites have been
> using the NeTraMet implementation for production traffic data
> collection, and others have used it as the basis of further
> developments in the field of network traffic measurement.  From
> this development work a need has arisen to extend the RTFM
> Architecture.
> 
> Furthermore, over the last few years interest in flow measurement
> has steadily increased, and many commercial products for this are
> now available.  Experience in this field indicates that although
> the current RTFM architecture provides a very general definition
> of flows and an effective method of collecting flow data, there is
> a clear need for new, standard approaches to this problem.
> 
> As well as extending the original RTFM architecture, the Working
> Group will develop new approaches to traffic flow measurement,
> as follows ..
> 
> Goals:
> 
>  1 Develop a standard for describing traffic flows, and for
>    reporting them from a meter to a flow flow data collection
>    system.  Such a standard would meet a clearly-expressed
>    need for many system vendors.
> 
>  2 Define a distributed metering architecture to support metrics
>    defined within the IPPM framework, e.g. one-way delay,
>    connectivity, one-way loss rate.  This architecture will
>    include remote packet capture, and will addres privacy
>    concerns such as the inadvertant disclosure of user
>    information and the need to authenticate and authorise
>    access to captured data.
> 
>  3.1 Develop a high-level interface to the current RTFM system,
>    so as to make RTFM capabilities easily and directly accessible
>    to new application programs.
> 
>  3.2 Standardise some of the 'new attributes' described in
>    RFC 2724.  Extend the RTFM architecture, e.g. by adding
>    'list-valued' attributes to the RTFM meter.
> 
> Milestones:
> 
> Documents
>  [questions, comments/suggestion please..
>     - what other documents will be needed?
>     - what should be in the documents (ideas for a
>         'contents' list for each would be very welcome!)
>     - who's volunteering to contribute to them?
>     - when could first drafts be ready?
>     ]
> 
>  * RTFM2 Flow Definition and Reporting Scheme
>        Defines a flexible description of flows which all vendors
>        can use when configuring meters.  The flow definitions
>        should be flexible enough to handle layer 2, 3 and 4/5
>        attributes, making them suitable for traffic engineering,
>        accounting, and network operations for at least all
>        IETF-specified protocols.
>        Specifies protocol for reporting flow data from meters.
> 
> 
>  * Requirements for Distributed Metering
> 
>  * Architecture for Distributed Metering
> 
>  * Remote Packet Capture Protocol
> 
>  * Distributing Metering Control Protocol
> 
>  * High-Level Interface to RTFM
> 
>  * Revised RTFM Architecture
>  * RTFM Meter MIB Extensions
> 
> -------------------------------------------------------------------------------

---

From: Stas Khirman <[email-masked]>
Date: Sat, 3 Feb 2001 18:38:24 -0800

Hi,

Last IETF meeting presentations and discussions show that "Remote Packet
Capturing" issues have natural relationship to the flow monitoring.  Are we
considering design of the "Packet Capturing" standards as the one of the
RTFM2 future goals ? Are we going to reflect our decision (positive or
negative) it in RTFM2 chapter?

On my personal opinion, practical implementation of the distributed flow
monitoring system have to include some sort of the packet (or part of them)
capturing and reporting (as described at draft-bullard-pcap-00.txt).  This
functionality is crucial for number of applications, such as protocol
recognition (using data signature of the first data packets) , off-line
analysis (OCxMON approach) and so on. From other hand, high data volume make
packet capturing impractical without flow aggregation and classification
(like it described in the draft-quittek-pcap-ext-00.txt). This consideration
make flow monitoring and selective packet capturing natural allies and, on
my personal opinion, have to be a considered by RTFM2 WG.

Sincerely
Stas Khirman

		-----Original Message-----
		From:	Juergen Quittek [mailto:[email-masked]]
		Sent:	Thursday, February 01, 2001 9:42 AM
		To:	Nevil Brownlee
		Cc:	[email-masked]
		Subject:	Re: DRAFT charter for proposed RTFM2 WG

		I'll send some followup messages starting a discussion on
these
		questions for each goal of the suggested charter. Please
anyone
		feel free to suggest further goals on this list.

		    Juergen
		-- 
		Juergen Quittek     [email-masked]     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

		>  * RTFM Meter MIB Extensions
----------------------------------------------------------------------------
---