RE: [bmwg] Is the BMWG a proper home for this I-D?ch

Russ White <ruwhite@cisco.com> Tue, 05 October 2004 19:22 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 PAA28881 for <bmwg-archive@lists.ietf.org>; Tue, 5 Oct 2004 15:22:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEumO-0007Kn-Hk; Tue, 05 Oct 2004 15:15:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEuj9-0005pY-4Y for bmwg@megatron.ietf.org; Tue, 05 Oct 2004 15:11:59 -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 PAA27470 for <bmwg@ietf.org>; Tue, 5 Oct 2004 15:11:57 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEusT-0003wY-KN for bmwg@ietf.org; Tue, 05 Oct 2004 15:21:38 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 05 Oct 2004 15:29:59 -0400
X-BrightmailFiltered: true
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i95JBOr5027162; Tue, 5 Oct 2004 15:11:25 -0400 (EDT)
Received: from russpc.Whitehouse.intra (rtp-vpn3-421.cisco.com [10.82.217.167]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03851; Tue, 5 Oct 2004 15:11:24 -0400 (EDT)
Date: Tue, 05 Oct 2004 15:10:56 -0400
From: Russ White <ruwhite@cisco.com>
To: Jim McQuaid <jim.mcquaid@netiq.com>
Subject: RE: [bmwg] Is the BMWG a proper home for this I-D?ch
In-Reply-To: <613E3F060982754CBF2FC6751E82679B05B225E9@ralexch01.netiq.local>
Message-ID: <Pine.WNT.4.61.0410051454490.3016@russpc.Whitehouse.intra>
References: <613E3F060982754CBF2FC6751E82679B05B225E9@ralexch01.netiq.local>
X-X-Sender: ruwhite@shako.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: hcb@gettcomm.com, sporetsky@quarrytech.com, bmwg@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Russ White <riw@cisco.com>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
Sender: bmwg-bounces@ietf.org
Errors-To: bmwg-bounces@ietf.org

> This thread is tending toward the "polemic."  I suggest we all obtain and 
> read the current charters for the WGs in question.  A charter can always 
> be amended, but it's a good starting point.

So, let's start with this: IPPM is in the transport working group, while 
BMWG is in operations. That seems to imply something different than 
anything said on this thread, thus far. IPPM seems to deal with traffic 
flow measurement, the measurement of transport, while BMWG seems to deal 
with network measurement, in terms of benchmarking. So, from this angle, a 
best practices on routing protocols convergence wouldn't fit within IPPM, 
since it's not a transport issue at all.

> I think the issue isn't so much "real world networks" versus "lab 
> networks." The original IPPM / BMWG split might be better thought of in 
> terms of audience.  IPPM was for network operators & planners.  BMWG was 
> one element of that, of course, but clearly *was* started with an eye 
> toward providing a standard to replace manufacturers marketing claims 
> back at the start of the router wars, so it was element-oriented and 
> somewhat more enterprise useful compared to network operator useful.

Even in terms of this, all the users of the tests you're talking about, the 
people using the products of the BMWG to evaluate vendor's testing, would 
be network operators, correct? So, that split doesn't make much sense to 
me, either, based on the terms listed here. If such a best practices 
document were to serve as guidance to test developers, I don't see where 
the conflict with what you're saying above comes in.

Now, finally, to the charters themselves. IPPM's charter says:

--

The IPPM WG will produce documents that define specific metrics and
procedures for accurately measuring and documenting these metrics.
The metrics are:

   - connectivity
   - one-way delay and loss
   - round-trip delay and loss
   - delay variation
   - loss patterns
   - packet reordering
   - bulk transport capacity
   - link bandwidth capacity

--

I don't see anything in there about routing protocols convergence, which is 
what the draft in question is/would be, if we continue to work on it. 
BTW--to make certain we come to agreement on at least this one point--the 
draft in question is about routing protocols convergence. Is there anyone 
who reads something else into it?

There's a section on measuring routing protocols convergence through 
traffic flow, but that's no different than 
draft-ietf-bmwg-igp-dataplane-conv-meth-03.txt. In fact, I don't see this 
document as being any different than draft-ietf-bmwg-hash-stuffing-00.txt, 
which is already a working group document. If we reject this document on 
those grounds, then the WG should reconsider the acceptance of those two 
documents, as well.

Based on IPPM's charter (quoted above) and area (transport), there's no way 
a routing protocols document would fit there.

Now, let's turn to BMWG's charter:

--

The major goal of the Benchmarking Methodology Working Group is to make
a series of recommendations concerning the measurement of the
performance characteristics of various internetworking technologies;
further, these recommendations may focus on the systems or services
that are built from these technologies.

....

An ongoing task is to provide a forum for discussion regarding the
advancement of measurements designed to provide insight on the
operation internetworking technologies.

--

I assume there's a missing "of" in the last sentence quoted above. Now, 
since this draft does/would apply to in the lab benchmarks, their 
construction and understanding their results, about specifically about an 
internetworking technology (routing protocols), and their performance.... I 
just don't see how this doesn't fit into the BMWG charter as it sits today. 
The last paragraph certainly implies this as well.

I don't read anything in the charter that limits the BMWG to only specific 
point tests, nor do I see anything placing routing protocols within IPPM's 
charter.

Does anyone see anything different in this?

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone


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