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

From: Kevin Dubray <[email-masked]>
Date: Wed, 07 May 2003 17:28:28 -0400

BMWG'ers:

A WG Last Call period for the Internet-Drafts regarding
OSPF convergence benchmarking terminology, methodology, and
benchmark applicability,

    <draft-ietf-bmwg-ospfconv-term-03.txt>,
    <draft-ietf-bmwg-ospfconv-intraarea-04.txt>,
    <draft-ietf-bmwg-ospfconv-applicability-02.txt>

will be open from 7 May 2003 until 17 May 2003.

These I-Ds contain modifications based on feedback from the previous
WG Last Call.

Please weigh in on whether or not you feel each individual draft
should not be given to the Area Directors for consideration in
progressing the draft to an Informational RFC.  Send your comments
to this list or [email-masked].

URLs for the Internet-Drafts are:

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraarea-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-02.txt

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

---

From: Russ White <[email-masked]>
Date: Sat, 10 May 2003 07:45:14 -0400 (Eastern Daylight Time)

The differences are, primarily:

Applicability Draft

-- Replaced all references with words rather than numbers.

-- Strengthened statements about difficulties in using these tests to
compare implementations.

-- Noted increasing sample size helps determine what is noise.

-- Added section on LSA/destination mix, order of LSA injection, and the
impact on performance of the topology shape.

-- Added section on topology generation, discussing emulators used to
generate topologies.

Convergence Draft

-- Replaced all references with words rather than numbers.

-- Added names for the reference topologies.

-- Moved the white box test for measuring spf time out of the "main text,"
as more of a note.

Terminology Draft

-- Replaced all references with words rather than numbers.

-- Inserted references to other documents where the same terms are defined.

-- Removed section on characterizations of the topology and their impact on
SPF. This was moved to the applicability draft.

:-)

rUSS

> http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applicability-02.txt

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Sat, 10 May 2003 07:45:14 -0400 (Eastern Daylight Time)

Applicability Draft

Convergence Draft

Terminology Draft

:-)

rUSS

---

From: Scott Poretsky <[email-masked]>
Date: Thu, 15 May 2003 19:57:56 -0400

BMWG-ers,

Reviewed the Terminology Draft.  Not much change from where we were in March.

Hadn't we had agreed that the existing terms would have references added 
and move to the "Existing Terminology" section?  4 of the 9 terms provided 
are from John Moy's OSPFv2 RFC.  Those are now referenced (weren't in the 
previous version), but the still need to go in "Existing Terminology".

Hadn't we agreed that defining Internal Measurement, External Measurement, 
and Multi-Device Measurements in this draft was inappropriate and would be 
removed?  We did because these are broad terms with a broad scope to the 
BMWG.  That now covers 7 of the 9 terms.

Hadn't we agreed that the term "Incremental-SPF" would not be included 
because it is implementation specific.  Cisco also does PRC.  Why not 
include that?  Avici does RTC.  Let's include that.  Of course this would 
go on and on so we decided to not include Incremental-SPF.  That is 8 of the 9.

The 9th term is "Shortest Path First Time".  Mitchell had posted for the 
previous version the comment "ADD... Some implementations may force a 
interval between
successive SPF calculations. If it exists, then this additional time
value should be subtracted from the total time.".  This is a great 
recommendation to add here in the Terminology draft.  In fact, some 
implementations have an SPF Delay and an SPF Holdtime.  The definition 
should state explicitly that measurement includes the SPF Delay, but the 
SPF HoldTime may be subtracted.  I also recommend that the term be changed 
to "Shortest Path First Execution Time".  That would then be the only 
remaining term.

There is one other new term introduced in the Terminology Document, Single 
Router Convergence (or SR-Convergence).  This definition should be added to 
the "Terminology" section as the second term rather than in the "Concepts" 
section where it is currently located.  I also recommend that based upon 
the other ongoing work for Data Plane Convergence that the "SR-Convergence" 
term be changed to "Control Plane Convergence" to eliminate confusion and 
match the way most people already speak.  Also, in the sentence 
"convergence will mean the point in time when the DUT has performed all 
actions needed to react to the change in topology represented by the test 
condition", it is recommended to change the word "all" to "some" because 
the Tree Building and FIB Update are not included in this measurement term.

Provided there is follow-up to the changes discussed in March and the 
additional changes for SR-Convergence, I would recommend the Terminology 
draft then be progressed to the ADs.

Scott

---

From: Russ White <[email-masked]>
Date: Fri, 16 May 2003 07:47:16 -0400 (Eastern Daylight Time)

> and move to the "Existing Terminology" section?  4 of the 9 terms
> provided are from John Moy's OSPFv2 RFC.  Those are now referenced
> (weren't in the previous version), but the still need to go in "Existing
> Terminology".

We had agreed to put in references, not to remove them from the draft. The
references are there. The actual discussions were pulled, but there is
discussion there that is not in the original reference points. Where else
would you put those discussions? In an "odd things we couldn't figure out
what to do with" section of the methdology draft, since they aren't
methodology? Or in the "things that don't really apply to applicability"
section of the applicability draft?

> Hadn't we agreed that defining Internal Measurement, External
> Measurement, and Multi-Device Measurements in this draft was
> inappropriate and would be removed?  We did because these are broad terms
> with a broad scope to the BMWG.  That now covers 7 of the 9 terms.

I don't recall such an agreement. As I recall, we had concluded that they
are not covered anyplace else, and they are referred to in the other
drafts, unless you can find some other place where they are defined.

> go on and on so we decided to not include Incremental-SPF.  That is 8 of

Not that I recall. iSPF is used as an example, in one of the drafts, about
how implementation type stuff can impact the performance numbers obtained.
In your opinion, it seems we need to either:

-- remove this section of the impacted draft, since we can't define the
term without defining every instance of implementation level details, and
we can't include the section unless we define the terms

-- remove the single example, and leave a single terse sentence in the
draft without any examples

-- add every known or possible example, to be fair

I find all of these alternatives unacceptable, since, again, iSPF is a well
known concept, but not defined any other place that I can find (in an rfc),
and we refer to it as an example.

> interval between successive SPF calculations. If it exists, then this
> additional time value should be subtracted from the total time.".  This
> is a great recommendation to add here in the Terminology draft.  In fact,
> some implementations have an SPF Delay and an SPF Holdtime.  The
> definition should state explicitly that measurement includes the SPF
> Delay, but the SPF HoldTime may be subtracted.  I also recommend that the
> term be changed to "Shortest Path First Execution Time".  That would then
> be the only remaining term.

We can add and subtract here. I don't have that email on my list of things
to change, don't know how I missed it.

> There is one other new term introduced in the Terminology Document,
> Single Router Convergence (or SR-Convergence).  This definition should be
> added to the "Terminology" section as the second term rather than in the
> "Concepts"  section where it is currently located.  I also recommend that
> based upon the other ongoing work for Data Plane Convergence that the
> "SR-Convergence"  term be changed to "Control Plane Convergence" to
> eliminate confusion and match the way most people already speak.  Also,
> in the sentence "convergence will mean the point in time when the DUT has
> performed all actions needed to react to the change in topology
> represented by the test condition", it is recommended to change the word
> "all" to "some" because the Tree Building and FIB Update are not included
> in this measurement term.

How does it not include tree building, if we're talking about spf times?
Isn't the definition of spf building the tree? I don't mind changing the
section it's in, and I don't care what we call the term. The term was
originally "invented" to get around the problem that a few people brought
up in calling what a single router does convergence. We were told we
couldn't call what happens on a single router "convergence," since
convergence, as a term, is applicable only to networks (regardless of the
dictionary definition of the term).

If people aren't going to raise the "convergence only happens in networks"
argument again, I'll be glad to do a search and replace, killing off
SR-convergence, and replacing it with convergence. As for whether you want
to add "control plane," I think that once we add control plane to SR, then
we wind up with:

CPSR-C
DPSR-P
TSP-C
CPN-C
DPN-C
TN-C

Do we really want to go one defining different terms for every aspect of
convergence we meet, or can we let the context sway the definition? Since
the drafts are about OSPF, I would normally take it that it only applies to
the control plane, within the context. I can see the usefulness in email,
if no context is set, but context is clearly set in these drafts, and I see
no reason not to just go with "convergence," without all the additions that
make it hard to read, just for technical precision.

Russ

---

From: Scott Poretsky <[email-masked]>
Date: Fri, 16 May 2003 10:27:35 -0400

At 07:47 AM 5/16/2003 -0400, Russ White wrote:

>We had agreed to put in references, not to remove them from the draft.

"Existing Terminology" is a section in all BMWG Terminology drafts.  This 
draft should also have it.

>The

You could create a Discussion section - "Discussion - Applying OSPF 
standard terms to OSPF Control Plan Convergence Benchmarking".

>drafts, unless you can find some other place where they are defined.

These terms have been used for years in BMWG documents.  It seems 
inappropriate to define the terms in a narrowly focused "Terminology for 
Benchmarking OSPF Control Plane Convergence" document.

>how implementation type stuff can impact the performance numbers obtained.

Exactly.  You use it in discussion to describe white-box 
implementation.  The term is not required to perform black-box benchmarking.

>known concept,

I have been trying to emphasize this point without mentioning vendors.  I 
now have to mention vendors, so I apologize to anyone who prefers 
mailing-list discussion remain vendor-agnostic (as I certainly do).  Recent 
NANOG presentations from Juniper, Cisco, and Avici indicate that only Cisco 
of those 3 implements incremental-SPF.  Since Avici and Juniper have faster 
convergence times then Cisco, Incremental-SPF is clearly not an 
implementation requirement.  The drafts could talk about Incremental-SPF, 
but it has nothing to do with benchmarking convergence.  I like the option 
of not discussing any vendor's implementation for convergence in IETF 
documents.

>but not defined any other place that I can find (in an rfc),

I think "Control Plane Convergence" makes all sides happy. It is also the 
way people speak.

>to add "control plane," I think that once we add control plane to SR, then

We do need to differentiate Data Plane Convergence in a single router from 
Control Plane Convergence in a single router.  Network Convergence refers 
to network convergence.  Data Plane Convergence and Control Plane 
Convergence refer to a single router.

>the drafts are about OSPF,

This raises another issue.  The Methodology draft applies to only OSPF 
intra-Area routes.  What about Inter-Area routes?  What about a mix of 
intra-area and inter-area routes in the route table, which is most often 
the case?  I am afraid the a methodology for only intra-area routes will 
not be of much use.  Did you plan to do additional methodologies for 
inter-area and a mix?

>I would normally take it that it only applies to

Of course, "convergence" cannot be the term applied to this work.  It is 
far too general.

Scott

---

From: Russ White <[email-masked]>
Date: Fri, 16 May 2003 11:01:27 -0400 (Eastern Daylight Time)

> draft should also have it.

So, you're stating we should move these to a section called "existing

> standard terms to OSPF Control Plan Convergence Benchmarking".

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.

> Benchmarking OSPF Control Plane Convergence" document.

Do you have references? Why not build a BMWG generic terminology draft? I
don't necessarily want to point to a BGP terminology draft, for instance,
for a definition used in this context, even if it means repeating the
defintion. It gets confusing to readers.

> Exactly.  You use it in discussion to describe white-box implementation.
> The term is not required to perform black-box benchmarking.

One of the tests described is a white box test, and we've already agreed
that removing that section is not what we want to do. It's been moved to a
"note" section, so it's not a primary part of the draft. So, again, we
either need one example, no examples, or tons of examples.

> I have been trying to emphasize this point without mentioning vendors.
> I now have to mention vendors, so I apologize to anyone who prefers
> mailing-list discussion remain vendor-agnostic (as I certainly do).
> Recent NANOG presentations from Juniper, Cisco, and Avici indicate that
> only Cisco of those 3 implements incremental-SPF.  Since Avici and
> Juniper have faster convergence times then Cisco, Incremental-SPF is
> clearly not an implementation requirement.  The drafts could talk about
> Incremental-SPF, but it has nothing to do with benchmarking convergence.
> I like the option of not discussing any vendor's implementation for
> convergence in IETF documents.

I'm glad you're very confident of your numbers. I would argue with them,
from my testing and experience. But let's try to stay on topic.

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. Is PRC? Is RST?
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.

Again, it's all a matter of providing at least one example, without
overwhelming the reader with an exhaustive list.

> We do need to differentiate Data Plane Convergence in a single router
> from Control Plane Convergence in a single router.  Network Convergence
> refers to network convergence.  Data Plane Convergence and Control Plane

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.

Can't we all figure out what it means using the context, so we don't need
to include it unless the context doesn't imply which it is.

> >I would normally take it that it only applies to the control plane,
> >within the context. I can see the usefulness in email, if no context is
> >set, but context is clearly set in these drafts, and I see no reason not
> >to just go with "convergence," without all the additions that make it
> >hard to read, just for technical precision.
>

Not from the outside, but from the inside. When you encounter the term
"bear" in a financial journal, you apply one definition. When you encounter
the term "bear" in an outdoors magazine, you apply another meaning to it.
The context sets the meaning.

Here, we have a draft which claims to provide a mechanism to measure the
time it takes to run spf on a single device, and you are saying we need to
use: "Single Router Control Plane Convergence," rather than the simpler and
easier to read term of art, "Convergence."

> not be of much use.  Did you plan to do additional methodologies for

Yes, we did plan on it.

Russ

---

From: Scott Poretsky <[email-masked]>
Date: Fri, 16 May 2003 18:41:52 -0400

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

>defintion. It gets confusing to readers.

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?

>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"?

>too much "vendor dependance" into the drafts.

There should not be any.

>overwhelming the reader with an exhaustive list.

You could provide plenty of examples for benchmarking convergence 
regardless of vendor implementation.    Would you like me to help?

> > >SR-convergence, and replacing it with convergence.

Why are you opposed to replacing it with "Control Plane Convergence" so 
there is not confusion with Data Plane Convergence benchmarks?

>As for whether you want

OK.  Good compromise that will prevent confusion.

>to include it unless the context doesn't imply which it is.

You are assuming too much if you expect context to provide definition.  The 
BMWG terminology drafts exist to ensure everyone knows the precise term and 
definition.  If we were to use context to define meaning then we would not 
need BMWG terminology drafts.  Of course, we would return to the same 
benchmarking confusion that existed before the BMWG did this work.

>easier to read term of art, "Convergence."

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.

> > not be of much use.  Did you plan to do additional methodologies for

This could take years.  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.

---

From: Russ White <[email-masked]>
Date: Fri, 16 May 2003 20:06:55 -0400 (Eastern Daylight Time)

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

> used for all BMWG drafts.  Are you writing that draft or the OSPF Control

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.

> An IETF guy citing an OSI document?  BTW, are you benchmarking ISIS or
> OSPF Control Plane Convergence?
>
> >Is PRC? Is RST?
>

> >too much "vendor dependance" into the drafts.

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.

> 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

---

From: Scott Poretsky <[email-masked]>
Date: Sat, 17 May 2003 08:10:02 -0400

I support draft-ietf-bmwg-ospfconv-intraarea-04.txt be given to the Area 
Directors for consideration in progressing the draft to an Informational 
RFC.  I have one question for the authors- why do these methodologies apply 
to only OSPF intraarea routes?  It seems that these same control plane 
convergence methodologies can be applied for OSPF inter-area routes and a 
mix of inter-area and intra-area routes, which is the practical scenario.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Sat, 17 May 2003 10:03:28 -0400

Russ,  Isn't this a global issue for the BMWG co-chairs and the people who 
regularly participate to drafts on the mailing list?  You only recently 
started participating on the mailing list and for that matter have 
commented on only YOUR drafts.  You even stay at the BMWG meetings only for 
your presentations, darting out as soon as done.  You should leave BMWG 
global issues to those who actively participate.

Kevin/Al,  If definitions for "External Measurements", "Internal 
Measurements", and "Multi-Device Measurements" remain in "OSPF Benchmarking 
Terminology and Concepts" then I wholeheartedly recommend IT IS NOT 
FORWARDED to the AD for consideration to be RFC.

BTW, The title should change.  The draft focuses on terminology and 
concepts for OSPF Single Router Control Plane Convergence.  The title makes 
it seem it is for all OSPF Benchmarking.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Sat, 17 May 2003 10:33:59 -0400

>easier to read, and more logical.

OK.  Then put it all in "Existing Terms".

>RFC'd, I'll be glad to refer to it.

See separate e-mail.

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

>            and it is expected to be dealt with in work that ensues from

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

>seems to be fine with them, or at least I infer that from the silence on

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

>problems, and get the job done one piece at a time, than to try and boil

I disagree to take this approach when it results in a document so diluted 
that is not of practical application.

Scott

---

From: Russ White <[email-masked]>
Date: Sat, 17 May 2003 11:30:21 -0400 (Eastern Daylight Time)

> OK.  Then put it all in "Existing Terms".

That's fine... Will do.

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

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

> 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

---

From: Russ White <[email-masked]>
Date: Sat, 17 May 2003 11:32:40 -0400 (Eastern Daylight Time)

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

---

From: Russ White <[email-masked]>
Date: Sat, 17 May 2003 11:36:44 -0400 (Eastern Daylight Time)

I agree that many of these same tests could be used for intraarea
measurements, but I also think there are unique tests that could be run for
intraarea and external route issues. I would like to see the intraarea and
external issues in a seperate draft, which refers to this draft as ways to
measure the more common elements of OSPF performance.

Thoughts?

:-)

Russ

---

From: Al Morton <[email-masked]>
Date: Sat, 17 May 2003 12:13:59 -0400

>Convergence is of far more interest than Control Plane convergence.

Not really, the new work proposal for Data Plane is an AND,
not an OR with Control Plane work,
also assuming significant progress there!

Saturday Morning Convergence would be good, too.

Al

---

From: Scott Poretsky <[email-masked]>
Date: Mon, 19 May 2003 19:47:19 -0400

Russ,

Since the test cases in this methodology can be used for inter-area, 
intra-area, and a mix, I recommend that no restrictions are placed upon the 
methodologies.  This would mean that the draft explicitly states it can be 
used for all the types of OSPF routes.  You can then write another draft 
for test cases specific to inter-area and a mix.

Scott

---

From: Scott Poretsky <[email-masked]>
Date: Mon, 19 May 2003 19:55:48 -0400

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

---

From: Scott Poretsky <[email-masked]>
Date: Mon, 19 May 2003 19:51:35 -0400

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

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 10:40:01 -0400 (EDT)

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

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 10:40:58 -0400 (EDT)

I'll let the rest of the wg speak up, if they're still awake out there....

??

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 10:41:35 -0400 (EDT)

Okay, which seems to imply we should change the name of the draft, and work
on the into section some.... Any other places?

:-)

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 20 May 2003 08:08:58 -0700

> What are the your votes?

this is the ietf, not the itu or ansi.  we don't vote.  we listen
to the expert opinions of our peers and think about it.

randy

---

From: Scott Poretsky <[email-masked]>
Date: Tue, 20 May 2003 14:07:45 -0400

>on the into section some.... Any other places?

I think all that would need to change is the Title and the 
Introduction.  The test methodologies would remain the same except for 
mention that each test case can be performed with Inter-area, Intra-area, 
or a mix of route types.

Scott

> > > > >http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-intraa 
> rea-
> > > 04.txt
> > > > >http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-applic 
> abil
> > > ity-02.txt
> > > > >
> > > > >
> > > > >

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 14:10:25 -0400 (EDT)

Okay, will do, and try to reissue these two this week.

:-)

Russ