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

[Scott Poretsky <[e-mail]>]

At 08:06 PM 5/16/2003 -0400, Russ White wrote:

> > >In the methodology draft to cover these terms? These were originally 
> in the
> > >definitions section of the methodology draft, but we put them in a 
> separate
> > >draft, over time, because we were requested to do so.
> >
> > I recommend that you list the existing terms with references in an
> > "Existing Terms" section and then provide discussion around those terms
> > in a separate Discussion section.
>
>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".


> > I absolutely agree there should be a general terminology document to be
> > used for all BMWG drafts.  Are you writing that draft or the OSPF Control
> > Plane Convergence draft?
>
>Until that draft is written, I believe these words need defitions. If you
>write one in the next couple of days, and get it through last call, and
>RFC'd, I'll be glad to refer to it.

See separate e-mail.


> > >Go back to the original IS-IS documentation. iSPF is mentioned there as a
> > >technique for improving spf time, but it's not fleshed out.
> >
> > An IETF guy citing an OSI document?  BTW, are you benchmarking ISIS or
> > OSPF Control Plane Convergence?
> >
> > >Is PRC? Is RST?
> >
> > Cisco implemented PRC.  Tell me - is it "fleshed out"?
>
> > >Are any others? I tried to use an example that was found in other public
> > >documents, not an example from Cisco's implemenation. Maybe you're reading
> > >too much "vendor dependance" into the drafts.
> >
> > There should not be any.
>
>I think you are _deliberately_ misreading what I'm saying. Let me make it
>clear:
>
>1. We have a side note about a white box test that is useful in evaluating
>the results of one of the outlined black box tests.
>
>2. The explanation of that white box test is improved by a single example
>of what sort of "spf optimization" it mentions.
>
>3. I chose as that example iSPF, because it is mentioned in relation to SPF
>in other public documents, and has been implemented at least once.

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.


>4. I also chose iSPF because it is simple to grasp the basic concept; most
>people who understand SPF will at least understand in theory how iSPF works
>(even if they couldn't implement it) with a short description. Not all
>other optimizations have this characteristic.
>
>5. I'm quite aware of other optimizations to SPF, but they have either
>been: not publicly documented in any way, or aren't in work relating to
>computer networks, or are hard to explain with a full sized paper on
>the topic.
>
>6. iSPF is _not_ vendor dependant.
>
> > Why are you opposed to replacing it with "Control Plane Convergence" so
> > there is not confusion with Data Plane Convergence benchmarks?
>
> > >And here I disgree. There is a large difference between control plane
> > >convergence on a network level and data plane convergence on a network
> > >level, a point I've made elsewhere. Again, if you want to be precise, be
> > >prepared to say: "Single Router Control Plane Convergence" each time you
> > >want to just type "Convergence," in every document that passes through 
> this
> > >working group.
> >
> > OK.  Good compromise that will prevent confusion.
>
> > I am absolutely stating that the term needs to include "Control Plane
> > Convergence".  If this draft were to use only "Convergence" then I would
> > have quite a solid argument that the definition should be data plane
> > instead of control plane.  We can compromise now to prevent that
> > discussion and at the same time prevent confusion that would result from
> > needing context to know what the benchmark means.
>
>       o    The interactions of SR-Convergence and forwarding; testing is
>            restricted to events occurring within the control plane. For-
>            warding performance is the primary focus in [INTERCONNECT]
>            and it is expected to be dealt with in work that ensues from
>            [FIB-TERM].

Please be aware that there is currently a call to accept IGP Data Plane 
Convergence Benchmarking as work items.


> From the intro of the convergence draft. I think that's enough context,
>myself.
>
> > This could take years.
>
>Only if you're making comments on them for years, really.
>Everyone else
>seems to be fine with them, or at least I infer that from the silence on
>the list.

BMWG-ers have made it clear on the mailing list that Data Plane Convergence 
is of far more interest than Control Plane convergence.


> > I can offer you some modifications to your proposed methodology so it
> > would apply to any type of OSPF route.  Convergence measurements with a
> > mix of inter-area and intra-area routes is of value.  Only intra-area is
> > of little value.
>
>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.

Scott


>Russ
>
>__________________________________
>[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