Subject: RE: charter goal

From: [email-masked]
Date: Wed, 7 Feb 2001 11:31:08 -0000

Hi,

We (BT labs UK) did some work with our own versions of RTFM for windows
boxes a couple of years back. The idea being that it would be useful to
network managers internally for network diagnostics of end nodes, which had
a RTFM meter running in the background. So we were trying to use RTFM to
address questions like ' why is my pc's network running slowly' what are the
'top ten networks visited by this node' etc.

Such questions ( requirements ?) lead us to have a certain view of what RTFM
should do ideally. Each of us based on our background probably have our own
individual ideas on what an idealised RTFM architecture should be able to
do.

But there are clearly certain areas of commonality.

Flow Capture  - Is implicitly 'limited' to the attributes of the MIB and
supporting SRL. In RTFM2 do we want to continue with the churn of adding
extra attributes, and language updates. Is SRL sufficient ? If we want RTFM
to be used in real world environments to help with debugging VOIP control,
MIP, tunnels services etc then a more open architecture/language needs to be
in place. Again along the same theme 'knowing' about control traffic of
upper protocols could be very useful and lead to a wider adoption of RTFM2,
but this is outside the current scope of RTFM capture. So do we want RTFM to
be a very generalised system for 'flow' capture above the current stack
limits, or is it sufficient just to keep within the current architecture
boundaries.

Flow Analysis - If RTFM2 had an extended architecture then this would
naturally follow, having trapped flows of a certain type basic analysis
could be used to check/detect certain service characteristics. For instance
an edge router could detect MIP nodes trying to find an agent. So knowing
you have an ICMP packet tells you very little without further analyis.

Flow Reporting (Post analysis) - Needs a real lift ! I know a push facility
has been talked about. Again a general architecture is need to enable RTFM
sinks to get the information in the way they want (not just the meter
manager). So you cannot second guess this, apart from being very flexible.
Push, pull, send event. Push being driven by a variety of ways, on a trigger
network event, under instructions from the RTFM sink (i.e. dump analysis
into this DB every hour, or analysis on these flows looks like a security
breach, send an alert event).

Visualisation - We found that to be used in the real world, we needed an
added layer. One that enabled managers to deploy a rule set, and view the
information that cameback in a variety of ways. This meant that for a given
ruleset the meter could provide a number of 'viewers' to provide differing
visualisation on the flow information, the viewers were responsible for
pulling the flows off based on their needs. So in an RTFM2 world, whilst we
may not want to be involved in this, we should bear in mind how the results
will be used. Of course if the flow reporting is extended, and in essence
forms a 'contract' between meter and sink then this could be sufficient.

In essence is RTFM (almost) a standard programable network stack component
or a 'vertical application' in its own right ?

These issues I feel should be addressed in any charter.

These of course are just my own personal views and do not represent any
company related standpoint.

Regards

Nick Farrow

BT Labs
UK

---

From: George Michaelson <[email-masked]>
Date: Thu, 08 Feb 2001 09:23:23 +1000

Vale nnstat. it was all so much simpler when the datarate was within the
processing power at hand.

I succeeded in using the caida tools with pcap to snarf enough packetflows
to find out some traffic shaping, it was a revalation that could still be
done. But I wouldn't base billing on it.

Which seems to me to say we're all dancing around netflow. Surely this
can't be good, to dangle on a provider-specific tool?

Um, is that cantrip on-charter?

-George

---

From: David Harrington <[email-masked]>
Date: Thu, 08 Feb 2001 09:16:29 -0500

At IETF49, Enterasys/Riverstone (previously Cabletron) announced that
the LFAP protocol was now open-source, and we are interested in having
the RTFM WG consider it as a proposed starting point for a
vendor-neutral industry standard for a push-style flow accounting
protocol extension to RTFM.

see http://www.nmops.org/draft-rfced-info-calato-01.txt for the latest
revision.

dbh

-- 
---
David Harrington            Network Management Standards Architect
[email-masked]           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA