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

[Scott Poretsky <[e-mail]>]

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
> >
> >
> > __________________________________
> > [e-mail] CCIE <>< Grace Alone
> >
> >
>
>__________________________________
>[e-mail] CCIE <>< Grace Alone
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg


_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg