Subject: Minutes of Pittsburgh RTFM meeting

From: Nevil Brownlee <[email-masked]>
Date: Fri, 4 Aug 2000 13:55:55 +1300 (DST)

Minutes of the RTFM get-together, Pittsburgh, Wed 2 Aug 00

The meeting was held in South 3, starting at 1140; nine people attended.

The main purpose of the meeting was to consider whether there are new
items which would justify restarting the RTFM Working Group.  For this
to happen we must produce Internet Drafts which describe the proposed
work items, making it clear why the item is something which needs to
be standardised, and demonstrating that there is good support for it.

Three possible work items were discussed:

1. A method of changing rulesets while they are running on an RTFM meter

   Marcelo Pias (BT, London) gave a short presentation of work done
   by himself and independently by Juergen Quittek (NEC, Berlin).

   The need here is for an API which can be used when developing new
   RTFM-based applications so that the developer
    - Doesn't have to understand the details of SNMP and the Meter MIB
    - Doesn't have to create rulesets using SRL

   Such applications would provide methods of
    - Creating new rulesets, and adding rules to them
    - Making a copy of a running ruleset
    - Interchanging a new ruleset with a running ruleset

   Rulesets created in this way would probably be fairly simple, but
   be targeted at particular application areas.

   The work item will include
    - Defining the API (and all the functions it provides)
    - Specifying any extensions to the meter architecture
      which are needed to support the API
    - Considering what happens to existing flows in a meter
      when a running ruleset is changed

*** Marcelo and Juergen will write an I-D: Generalised Meter Interface

2. Extending the RTFM Architecture (and Meter MIB) to cover some
   of the New Attributes

   Nevil Brownlee (University of Auckland) has implemented all of
   the distribution-valued attributes from RFC 2724, and has about
   18 months of experience in using them.  These need to be added
   to the Architecture document, and the Meter MIB needs to be 
   extended so as to describe how distribution values are stored
   and retrieved.

   Recently a need for a new kind of attribute value - list-valued -
   has arisen, as follows.  
    - All of the RTFM address attributes have values in each 
      packet for both directions of their flow, e.g. every packet 
      has values for both SourcePeerAddress and DestPeerAddress.  
      The RTFM packet-matching algorithm depends on having both of 
      these, so that they can be swapped when attempting a match in 
      the reverse direction
    - Attributes such as DSCodePoint and NetFlow's NextHop have only
      one value in each packet, hence they can't be used in packet
      matched
    - Instead, we can build two tables of (value, count) pairs, one
      for each direction of the flow.  I describe such a pair of
      tables as a list-value

*** Nevil will write an I-D: RTFM Attribute Extensions

3. A Standard Packet Capture Architecture

   Carter Bullard (Quotient) raised the need for new architecture
   for capturing packets.  Packet capture would be done on a remote
   box, with the captured packets (from one or more such boxes) sent
   back to a central point.  Design goals for the system include:
    - Capture packets efficiently at high link speeds
    - Record accurate (sub-microsecond) timestamps for each packet
    - Record only a specified part of each packet, e.g. IP header,
      UDP/TCP header,  first n bytes of payload, etc.
    - Provide various kinds of filtering and/or sampling, e.g.
      only UDP/DNS packets, only packets to/from 10.0.0.1, 
      every nth packet, etc.
    - Packets should be sent to the central point with a header
      which includes the timestamp, the interface and the host it
      was captured on

   Such a packet capture system could sit well with an RTFM meter, or
   within an RMON probe (probably depending on whether one wants to
   specify filters using RTFM attributes or RMON protocol IDs); 
   Carter will talk to RMON and IPPM about it.

   Georg Carle (GMD-Fokus, Berlin) also has a strong interest in
   this activity.  He presented some slides of his proposed
   architecture for policy-based packet capture, including
   authorisation and sampling algorithms.

*** Carter and Georg will write an I-D: Packet Capture Architecture

Next steps:

The people listed above will write their I-Ds, posting copies to the
RTFM list from time to time.  When the I-Ds are complete the authors 
will publish them as individual I-Ds (they can't be RTFM I-Ds since 
the RTFM WG is dormant).

Once the I-Ds are published I'll ask our ADs for a BOF session at the
next IETF, i.e. San Diego in December 2000.  To do this we should aim
to get the I-Ds published by the beginning of October.

The meeting finished at 1355.

Notes by Nevil Brownlee.

Disclaimer: 
   I've expanded my written notes with what I remember of our
   discussions.  If I've got it wrong, please post corrections 
   to the list.

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

Marcelo has sent me a copy of his slides.  I'll put them (together with 
these minutes and any other presentation slides) on the RTFM web page.

Cheers, Nevil

+---------------------------------------------------------------------+
| Nevil Brownlee                     Director, Technology Development |
| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
|   FAX: +64 9 373 7425      Private Bag 92019, Auckland, New Zealand |
+---------------------------------------------------------------------C