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

[Scott Poretsky <[e-mail]>]

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


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