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

[Russ White <[e-mail]>]

> >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.

> 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.

> >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.

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].

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.

> 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.

Russ

__________________________________
[e-mail] CCIE <>< Grace Alone

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