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

[Russ White <[e-mail]>]

'kay--i can see what you're saying. I'll pull the term, but leave the
discussion in the other draft.

:-)

Russ

On Mon, 19 May 2003, Scott Poretsky wrote:

> Incremental-SPF is a white box implementation.  Convergence Benchmarks can
> be made with any internally implemented convergence
> algorithm.  Incremental-SPF can be discussed, but I am opposed to it
> appearing as an "official" term defined in the Terminology draft.  If it
> were to remain a term then I recommend the terminology draft IS NOT
> FORWARDED to the AD for consideration to be RFC.
>
> Scott
>
>   At 11:30 AM 5/17/2003 -0400, 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