[ippm] IPPM MIB

"Henk Uijterwaal (RIPE NCC)" <henk@ripe.net> Mon, 16 August 2004 08:58 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19230 for <ippm-archive@lists.ietf.org>; Mon, 16 Aug 2004 04:58:12 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd8D-0008NQ-6p; Mon, 16 Aug 2004 04:46:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bwd5v-0007td-0g for ippm@megatron.ietf.org; Mon, 16 Aug 2004 04:43:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18578 for <ippm@ietf.org>; Mon, 16 Aug 2004 04:43:53 -0400 (EDT)
Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BwdBc-0004u1-A3 for ippm@ietf.org; Mon, 16 Aug 2004 04:49:52 -0400
Received: by postman.ripe.net (Postfix, from userid 8) id 48C984E313; Mon, 16 Aug 2004 10:43:19 +0200 (CEST)
Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id DFEEF4E087 for <ippm@ietf.org>; Mon, 16 Aug 2004 10:43:18 +0200 (CEST)
Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i7G8hIW7007931 for <ippm@ietf.org>; Mon, 16 Aug 2004 10:43:18 +0200
Received: from localhost (henk@localhost) by x49.ripe.net (8.12.10/8.12.6) with ESMTP id i7G8hIbR030126 for <ippm@ietf.org>; Mon, 16 Aug 2004 10:43:18 +0200
X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs
Date: Mon, 16 Aug 2004 10:43:18 +0200
From: "Henk Uijterwaal (RIPE NCC)" <henk@ripe.net>
To: ippm@ietf.org
Message-ID: <Pine.LNX.4.58.0408161042590.27592@x49.ripe.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled
X-RIPE-Signature: 645a42a8c69c7db47482cdeb562e1335
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Subject: [ippm] IPPM MIB
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org >
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=unsubscribe>
List-Post: <mailto:ippm@ietf.org >
List-Help: <mailto:ippm-request@ietf.org ?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org ?subject=subscribe>
Sender: ippm-bounces@ietf.org
Errors-To: ippm-bounces@ietf.org

IPPM group,

Since the IPPM WG meeting in Seoul, there have been several discussions
(both public and private) between Emile Stephan, Andy Bierman (the IPPM
MIB technical advisor), the chairs of the WG and several others, on how to
proceed with the IPPM MIB document (draft-ietf-ippm-reporting-mib-06.txt).
This mail summarizes the discussions and proposes a way forward.

We all agree that even though the current draft is in its 6th iteration,
there has been very little feedback from the WG on its contents.  The
chairs did receive some informal comments on the document, these can be
summarized as "the document and MIB are too complex".

A proposal has been made to for a simpler approach, based on a ring buffer
to store individual measurements.  While this looked nice in theory, in
practice it is probably not possible to store and retrieve individual
measurements in a MIB at a rate of the order of 1Hz or more. In other
words, a MIB can only be used to report aggregate information, where the
aggregation is done either on demand or by default at regular intervals.

As the next steps, we propose:

1. The mailing list will be asked to provide feedback on the question
   what information they would like to see in the management interface
   of a network measurement system. (See below).

2. When there is consensus on this question, we will look at existing
   MIB's (in particular the RMONMIB TPM-MIB) to see what is
   already there to satisfy the requirements generated in the previous
   step and what has to be defined in our group.

3. The existing document will be rewritten to define whatever has to be
   defined and nothing more.

If there is little or no feedback on step 1, we will conclude that there
is no interest in an IPPM at the moment.  In that case, the existing
document will be finished and a published as an informational RFC.

To start, the first questions we would like to see answered, are:

* What information would you like to see in a management interface of a
  measurement system?
* What action would you like to take with a management interface of a
  measurement system?
* Do you have requests from the users of your implementation of the
  IPPM metrics for an interface between the measurement system and
  a network management system (NMS)?

Please note the constraint mentioned above. It also should be noted that
some of the IPPM metrics implementations do not use a MIB but do report
aggregated information in other formats (CSV, XML, graphical, ...)  This
is information that could (potentially) be reported in a MIB as well.

We invite everybody to comment on both the procedure and the questions
above before September 30,

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Process and Procedure are the last hiding place of people without the wit
and wisdom to do their job properly.                          (David Brent).

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm