Subject: RTFM2 BOF minutes, mailing list info

From: Nevil Brownlee <[email-masked]>
Date: Mon, 8 Jan 2001 16:43:47 +1300 (New Zealand Daylight Time)

Hello all:

Herewith the minutes of the RTFM2 BOF held at the 49th IETF meeting
in San Diego.

I've updated the RTFM web page (www.auckland.ac.nz/net/Internet/rtfm)
to include these minutes, with PowerPoint files for each of the 
presentations at the meeting.  The web page also has information about
this mailing list and its archive.

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

Minutes of the RTFM2 BOF, Thursday, December 14, 2000
Co-chairs: Brownlee, Bullard, Quittek

One-para summary ..

133 people attended, four Internet Drafts were presented.  They
were well-received and generated enthusiastic discussion.  Strong
support - and interest in participating and contributing - was
expressed for a Working Group not only to develop these drafts,
but also to address three further issues: push technology in the
RTFM traffic Meter, a standard method for describing and reporting
flows, and the development of a distributed metering system.

133 people were present About 1/3 of those present had some
understanding of RTFM, making further introductions unnecessary.
The agenda (as on the IETF meeting pages) was accepted without
comment. 

Nevil Brownlee presented his draft on 'Implementing New
Attributes,' which proposes to implement enhancements to the
current RTFM architecture.  Most of these are part of RFC 2724, but
'list-valued' attributes and flow-size filters are new.
Discussion:
 * Is it better to measure flows in the core or at access points?
   Performance issues may require us to modify abstraction; some
   discussion of core vs edge in the draft is needed.
 * Could you measure BER within the RTFM framework?  Because of
   layer boundary issues BER may not be a measurable metric.
 * It may be hard to measure loss or delay because of asymmetric
   and performance issues.  This may need to be addressed in
   the framework.

Juergen Quittek presented his draft on 'High-Level Interface to the
Traffic Flow Measurement Architecture.' This proposes an improved
interface for managing RTFM meters, making it easier to use them in
network operations.  Questions:
 * Definition of flows, interface sand some specific applications
   are similar to those in INTSERV.  It would be interesting to
   align flows and flow characterizations with those in the
   INTSERV definitions. 
 * The current RTFM meter control and data-gathering interfaces are
   not clearly distinguished.  This could be improved.  (Dan Romascanu)
 * Accounting systems (used by ISPs) uses push technology, which is
   popular.  The RTFM architecture would be improved if it included
   the ability to push flow data.
 * Many vendors have proprietary strategies for flow collection
   and analysis.  A new high-level interface should allow for more
   general flow collection mechanisms.
 * The RTFM architecture document (RFC 2722) emphasises
   bi-directional monitoring above other modes of operation,
   suggesting that when you can't see both sides of the flows, the
   RTFM architecture would break down.  This needs to be
   better explained.

Carter Bullard presented his draft on Remote Packet Capture, which
would allow the capture of specified headers within packets at very
high speeds, and their transmission (with a 'captured packet
encapsulation header') back to a central metering point. 

Georg Carle briefly presented his draft on Packet Capture
Extensions, which proposes more efficient filtering and packaging
of remotely captured packets before they are transmitted to the
metering point. 

Both speakers emphasised the need to address privacy concerns.  In
particular, the disclosure of user is addressed by both proposals,
together with the need to authenticate and authorise access to
captured data.  Comments:
 * How should we address clock synchronisation concerns?  This is
   well covered within the IPPM Framework.
 * This proposal introduces a lot of new functionality, which
   vendors may find difficult to integrate into their products.
   We intend to get some chip manufacturers involved so as to
   ensure that the proposal can actually be implemented.
 * Does packet capture belong within RTFM2?  RMON and RTFM are
   the primary IETF technologies that would use this form of
   packet capture, and RMON has a busy work schedule for most of
   next year.  RTFM2 will work co-operatively with RMON and IPPM
   to develop this proposal.
 * Support - indeed commitment - was expressed for the development
   of distributed metering systems within RTFM2.
 * Can this be done at OC192?  Yes, provided we can get chip
   manufacturers involved in the project.  The important thing
   for RTFM2 is to produce a clean specification for packet capture.

Conclusion ..

The meeting provided two hours of interesting discussion.  Support
was expressed for the goals outlined in the BOF charter (2/3
audience raised hands), i.e. 
a) Standardise some of the 'new attributes' described in RFC 2724.
   Extend the architecture, e.g. by adding 'list-valued'
   attributes to the RTFM meter. 
b) Develop a high-level interface to RTFM, so as to make RTFM
   capabilities easily and directly accessible to new application
   programs.
c) Develop a high-speed remote packet capture ability, so as to
   provide a distributed source of packet data for RTFM meters.

However, the discussion introduced three further goals, i.e.:
1. Push technology issues in RTFM.
2. Standard for flow reporting.
3. Distributed metering..

Several attendees committed themselves to contribute to the 
proposed RTFM2 WG.

The BOF co-chairs proposed to send minutes of this meeting,
together with a proposed charter for a new Working Group ,to the
RTFM mailing list for further discussion.  When rough consensus is
reached, the co-chairs will discuss the proposed charter with our
Area Directors, before asking them to submit it to IESG. 

This proposal was strongly supported.

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