Re: [bmwg] WG Last Call: OSPF convergence benchmarking

Russ White <ruwhite@cisco.com> Tue, 20 May 2003 14:39 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16033 for <bmwg-archive@odin.ietf.org>; Tue, 20 May 2003 10:39:53 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KE9MZ05158 for bmwg-archive@odin.ietf.org; Tue, 20 May 2003 10:09:22 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KE91B05114; Tue, 20 May 2003 10:09:01 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KE8eB05096 for <bmwg@optimus.ietf.org>; Tue, 20 May 2003 10:08:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15982 for <bmwg@ietf.org>; Tue, 20 May 2003 10:38:41 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I8I1-0005jT-00 for bmwg@ietf.org; Tue, 20 May 2003 10:40:29 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19I8I1-0005jC-00 for bmwg@ietf.org; Tue, 20 May 2003 10:40:29 -0400
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4KEf4Jh018076; Tue, 20 May 2003 10:41:04 -0400 (EDT)
Received: from dhcp-64-102-48-215.cisco.com (dhcp-64-102-48-215.cisco.com [64.102.48.215]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA04910; Tue, 20 May 2003 10:41:04 -0400 (EDT)
Date: Tue, 20 May 2003 10:40:58 -0400
From: Russ White <ruwhite@cisco.com>
Reply-To: Russ White <riw@cisco.com>
To: Scott Poretsky <sporetsky@avici.com>
cc: bmwg@ietf.org
Subject: Re: [bmwg] WG Last Call: OSPF convergence benchmarking
In-Reply-To: <5.0.2.1.2.20030519194814.027a17b0@pop.avici.com>
Message-ID: <Pine.OSX.4.51.0305201040380.20853@dhcp-64-102-48-215.cisco.com>
References: <Pine.WNT.4.55.0305171123200.1392@russpc> <5.0.2.1.2.20030516181749.0276abf8@pop.avici.com> <5.0.2.1.2.20030516100709.027d2fc8@pop.avici.com> <5.0.2.1.2.20030515191932.027d3770@pop.avici.com> <5.0.2.1.2.20030515191932.027d3770@pop.avici.com> <5.0.2.1.2.20030516100709.027d2fc8@pop.avici.com> <5.0.2.1.2.20030516181749.0276abf8@pop.avici.com> <5.0.2.1.2.20030517102354.02860e28@pop.avici.com> <Pine.WNT.4.55.0305171123200.1392@russpc> <5.0.2.1.2.20030519194814.027a17b0@pop.avici.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
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>

I'll let the rest of the wg speak up, if they're still awake out there....

??

:-)

Russ

On Mon, 19 May 2003, Scott Poretsky wrote:

> The options we came up with were
>
> a. single router control plane convergence
> b. control plane convergence
> c. single router convergence
> d. convergence
>
> I like _a_.  While long, it is specific.  In our world of acronyms it will
> be reduced to srcpc anyway.
>
> What are the your votes?
>
> Scott
>
> At 11:32 AM 5/17/2003 -0400, Russ White wrote:
>
> >Oh, and if you think we should rename the draft to more closely relate to
> >the methodology draft, I'm fine with that. I don't want the entire working
> >group to the be stuck using "single router control plane convergence"
> >constantly in every doecument published.
> >
> >We should come to agreement that you can set the context in the naming and
> >the draft abstract, and then use the words that make the most sense within
> >the context thus set. I do like precise definitions, but using long phrases
> >to replace a single word in the name of precision I find annoying as a
> >reader.
> >
> >Russ
> >
> >On Sat, 17 May 2003, Russ White wrote:
> >
> > >
> > > > >I would prefer to leave the discussion with the references. It would be
> > > > >easier to read, and more logical.
> > > >
> > > > OK.  Then put it all in "Existing Terms".
> > >
> > > That's fine... Will do.
> > >
> > > > Re-read what you wrote in the draft.  Incremental-SPF does not contribute
> > > > anything to the Black-Box tests nor White-Box tests.  The same White-Box
> > > > discussion can be made successfully without mentioning Incremental-SPF.
> > >
> > > They can be made without mentioning it, but the statement is made that
> > > there are things in an spf implementation which do impact the run times of
> > > spf, and may not be apparent from the outside. Either I can give no example
> > > here, or I need to give an example, to edify the readers of the draft of
> > > what sort of thing we are talking about.
> > >
> > > I looked at all possible enhachements (changing the sort on the tent,
> > > PRC, iSPF, and others), and concluded that I could explain iSPF in the
> > > shortest period, without delving into a lot of technical detail. Since iSPF
> > > is not implementation specific, as far as I know, I still don't see the
> > > problem with including it as an example, and providing a short explanation
> > > of what it is to readers.
> > >
> > > > Please be aware that there is currently a call to accept IGP Data Plane
> > > > Convergence Benchmarking as work items.
> > >
> > > I know that, my point is that this is not a data plane draft, and it
> > > clearly states this up front, in the draft. Since the terminology draft
> > > clearly relates to the methodology draft, I don't understand what the issue
> > > is with allowing the context to determine the meaning.
> > >
> > > > BMWG-ers have made it clear on the mailing list that Data Plane
> > > > Convergence is of far more interest than Control Plane convergence.
> > >
> > > That's fine, but I find it more useful to be able to characterize them
> > > seperately. My experience, partially embodied in the network benchmarking
> > > considerations draft, is that you can't really do justice to understanding
> > > a network unless you understand both the micro and macro issues.
> > >
> > > > >We decided to narrow the focus of the draft because of our
> > experience with
> > > > >other drafts that tend to cover a large area and take forever to get
> > > > >through the working group. It's easier to split the problem up into
> > smaller
> > > > >problems, and get the job done one piece at a time, than to try and boil
> > > > >the ocean.
> > > >
> > > > I disagree to take this approach when it results in a document so diluted
> > > > that is not of practical application.
> > >
> > > Narrowing normally concentrates, rather than dilutes.... If you think the
> > > draft is too narrow, that's fine. I'd rather leave it seperate, and let the
> > > next step be doing the interarea stuff. OSPF on an ABR or ASBR is a
> > > different beast than OSPF in pure intraarea environments.
> > >
> > > I prefer chewing smaller bites, rather than larger ones, if at all
> > > possible.
> > >
> > > Russ
> > >
> > >
> > > __________________________________
> > > riw@cisco.com CCIE <>< Grace Alone
> > >
> > >
> >
> >__________________________________
> >riw@cisco.com CCIE <>< Grace Alone
> >
> >_______________________________________________
> >bmwg mailing list
> >bmwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/bmwg
>
>

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

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