Subject: Re: OSPF WG Charter Proposal

From: Manohar Naidu Ellanti <[email-masked]>
Date: Wed, 6 Nov 2002 21:50:57 +0000

Jerry,
your comment -
"Fortunately such failures are very rare;
however, 'rare' for such events is unacceptable, 'never'
is the goal.  Other service providers have experienced
similar outages caused by similar problems." is very apt.

You have probably the most qualifying experience to talk
about control protocol.

I would like to raise the following questions
 - OSPF as it is , is it suitable to advertise auxiliary
information
- is the network model right ? spoke and wheel as
opposed to hierarchical model.
-can the protocol be simplified ; it is becoming too
monolithic
If you look at SS7  there is clear seperation of
applications from signaling protocol- comparison of OSPF
to SS7 may not make sense but if you look #7
architecturally - ISUP, TUP etc are applications on top
of signaling/control protocl.

I have asked long time back about breaking the
monilithic function of OSPF into applications/seperate
functions that can use the OSPF basic services rather
than the applicaitons being part of OSPF itself. But no
body seems to be interested or it is too late.

If  applications and their information elements (TLVs)
are seperated from OSPF it woul be feasible to reduce
OSPF LSA congestion as the LSDB itself will be segmented
or the information stored in LSDB can migrate to the
applications themselves. Just my opinions.

-ellanti
> Rohit, Acee,
>
> From the (consolidated) thread so far:
>
> Rohit/Acee> Here is a strawman of the Charter. Please have a look at and send
> Rohit/Acee> any comments you may have to me or Acee or to the list.
>
> Venkata> Can you consider "Flooding Optimizations" into charter?
> Venkata> If not, can you please explain the reason, why we should not?
> Venkata> This is field of its own - we might expect lot of drafts.
>
> Rohit> We considered this but would like to see some operational requirements
> Rohit> before including this in the charter. Is anybody running OSPF networks
> Rohit> hitting this problem with no workarounds in sight?
> Rohit> It would be a candidate for a future version of the charter once some
> Rohit> of the current items clear.
>
> Vishwas> I do think it can be helpful in a few cases. A recent paper by Aman
> Vishwas> Shaikh/Albert Greenberg et.al. about analyzing OSPF for Enterprise
> Vishwas> is one such case.
> Vishwas> One of our drafts "Congestion Avoidance and Control for OSPF networks"
> Vishwas> talks about problems that have been caused by flooding overload in
> Vishwas> production networks.
>
> Rohit> I am familiar with Aman's work. The problem identified there was
> Rohit> that of (a) sub-optimal network/ospf configuration and (b)
> Rohit> broken router.
> Rohit> This does not of course justify building new protocol mechanisms,
> Rohit> thereby complicating the protocol.
> Rohit> I will look at the congestion again to see if/why it concludes otherwise.
>
> We would like to see OSPF 'congestion control' included into the OSPF charter,
> where 'flooding optimizations' is a key component as discussed in our draft
> http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.
> txt.  We can propose a workplan/goals/milestones if you'd like.
>
> Several other drafts identify needs related to OSPF congestion control:
> http://ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt
> http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-0
> 0.txt
> http://www.ietf.org/internet-drafts/draft-dovolsky-ccamp-ospf-limited-flooding-0
> 0.txt
>
> AT&T has suffered a few massive failures of operational networks due to control
> overloads of link-state (LS) protocols ('OSPF', 'PNNI', etc.).  These outages
> are documented and referenced in our draft (and in
> http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02
> .txt).
>
> In the instances cited, the link-state protocol overwhelmed the network with a
> control load 'storm' ('LSA overload'), which brought the network down, and then
> prevented its recovery.  Fortunately such failures are very rare; however,
> 'rare' for such events is unacceptable, 'never' is the goal.  Other service
> providers have experienced similar outages caused by similar problems.
>
> Such failures are not the fault of the service provider operation or the
> vendor/equipment implementation.  They are due to shortcomings in the link-state
> protocols themselves -- thus the need for the enhancements proposed in the
> draft.
>
> The proposals in
> http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.
> txt will prevent such events from being triggered, and/or provide recovery
> mechanisms in case such events occur.
>
> The problem of control overload is becoming even more acute as LS protocols are
> enhanced to support new capabilities, such as:
>
> MPLS traffic engineering
> http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt,
> GMPLS
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-08.tx
> t,
> multi-area TE
> http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt,
> MPLS/DiffServ TE
> http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-06.txt,
> etc.
>
> With this ever advancing complexity, the need keeps increasing to address the
> stated problem, soon.  Thus the need for the charter item on OSPF congestion
> control.
>
> Thanks,
> Jerry Ash

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 7 Nov 2002 10:34:53 -0500

There seem to be multiple things mixes together in this discussion, some of
which are nicely separated in the draft below.

One set of things are behaviors like pacing link start, pacing flooding,
marking critical packets, etc.  These have a number of useful
properties.  They improve the overall result without changing the basic
mechanisms.  They do not introduce significant risk of interaction between
mechanisms.

A second set of things mentioned are issues like hitless restart.  While
these have more impact, they have benefits in a number of different
regards, and can be evaluated on their own merits.

Then there are manual mechanisms to help flooding in very meshy
topologies.  While somewhat dangerous, these have proved
necessary.  Because they are manual, they can be applied with sensitivity
to their overall topology impact.

Then there are automatic information distribution change mechanisms.  This
covers such things as automatic area change and alternative flooding
algorithms.  These are extremely dangers.  They interact very strongly with
the basic robustness mechanisms of OSPF.  They introduce significant
additional complexity in many regards.  I strongly suggest that we stay
away from any such behaviors, and ensure that our charter keeps us away
from them.

Yours,
Joel M. Halpern

At 08:27 AM 11/7/2002 -0500, Ash, Gerald R (Jerry), ALASO wrote:
>Dave,
>
> > > Such failures are not the fault of the service provider
> > > operation or the vendor/equipment implementation.  They are
> > > due to shortcomings in the link-state protocols themselves --
> > > thus the need for the enhancements proposed in the draft.
>
> > I strongly disagree with this statement.  While the design of the
> > protocols can make it challenging, there is ample room in
> > implementation to provide stable and scalable networks.
> >
> > When a network collapses, the fault lies at the feet of the
> > implementers.  In every case I've seen (too many), the collapse was
> > inevitable sooner or later, due to naive design choices in software,
> > but at the same time was quite nonlinear in its onset (making any
> > predictive or self-monitoring approach pretty hopeless.)
> >
> > There are some things that would make the job easier, at the cost
> > of additional complexity, but pointing at network collapses
> > and blaming the protocols is disingenuous.
>
>I think you should review the ample evidence presented in
>http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt
>that the protocols need to be enhanced to better respond to congestion
>collapse:
>
>- Section 2: documented failures and their root-cause analysis, across
>multiple service provider networks (also review the cited references)
>- Appendix B: vendor analysis of a realistic failure scenario similar to
>one experienced as discussed in Section 2 (perhaps you would like to
>provide your own analysis of this scenario based on your OSPF implementation)
>- Appendix C: simulation analysis of protocol performance (other I-D's
>being discussed provide analysis of proposed protocol extensions)
>
>To say that network collapse in *every* case is due to *naive design
>choices* ignores the evidence/analysis presented.  Based on the
>evidence/analysis, there is clearly room for the protocols to be improved
>to the point where networks *never* go down for hours or days at a time
>(drawing unwanted headlines & business impact).
>
>Jerry

---

From: John Drake <[email-masked]>
Date: Thu, 7 Nov 2002 08:27:27 -0800

Tony,

You saved me some typing.  As another example, implementations of PNNI
signalling ranged from something like ten calls per second to several
thousand calls per second.

Thanks,

John

-----Original Message-----
From: Tony Przygienda [mailto:[email-masked]]
Sent: Thursday, November 07, 2002 8:17 AM
To: [email-masked]
Subject: Re: OSPF WG Charter Proposal

>I think you should review the ample evidence presented in
http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control
-00.txt that the protocols need to be enhanced to better respond to
>- Appendix B: vendor analysis of a realistic failure scenario similar to
one experienced as discussed in Section 2 (perhaps you would like to provide
your own analysis of this scenario based on your OSPF implementation)
choices* ignores the evidence/analysis presented.  Based on the
evidence/analysis, there is clearly room for the protocols to be improved to
the point where networks *never* go down for hours or days at a time
(drawing unwanted headlines & business impact).
>Jerry
Jerry, most of the things you say in your document (which is actually
pretty good) has been
known to people like Dave and other old-time implementors since years
and avoiding exactly
those things by smart implementation techniques was what was
differentiating the have from
the have-nots. I remember myself learning some of those things by hard
experience and some
by looking at old-hands code ;-) [Albeit I remember also picking up a
lot of smart control protocol
ideas from your RTNR work]. I do not think that Dave is putting down
what you say, rather
(and I commit the stupidity to interpret his words by my own beliefs)
that what your document
says are mostly _implementation_ issues, not _standardization_ and
therefore it is not a very wise
idea to add them to the charter of a _standards_ group.  Good protocol
specs are _not_
implementation cookbooks, they are documents governing bits on the wires
in such a way that
two people implementing things in vastly different ways can still talk
to each other. Recommendations
of implementation techniques prove long-term inherently dangerous (like
Joel pointed out, at a
certain point in time adding more code to an implementation introduces
more bugs than the
performance gain is worth) or utterly ridiculous (look at ISIS 0-63
metric to make SPF real fast,
it lead to quite bad contortions).

    thanks

    -- tony

---

From: Jeff Parker <[email-masked]>
Date: Thu, 7 Nov 2002 11:48:38 -0500

> As another example, implementations of PNNI

In the context of this discussion, I'm not sure which
of the two statements below you are making.  (#1?)

        "So efficient that we could make
        thousands of setups per second"
or
        "So out of control that we would make
        thousands of calls per second."

- jeff parker

---

From: "Manral, Vishwas" <[email-masked]>
Date: Thu, 7 Nov 2002 12:49:24 -0500

Hi Joel,

> There seem to be multiple things mixes together in this discussion,
> some of which are nicely separated in the draft below.

> One set of things are behaviors like pacing link start, pacing
> flooding, marking critical packets, etc.  These have a number
> of useful properties.  They improve the overall result without
> changing the basic mechanisms.  They do not introduce
> significant risk of interaction between mechanisms.
I agree totally.

> A second set of things mentioned are issues like hitless
> restart.  While these have more impact, they have benefits in a
> number of different regards, and can be evaluated on their own
> merits.

> necessary.  Because they are manual, they can be applied with
> sensitivity to their overall topology impact.
I agree here too.

> Then there are automatic information distribution change
> mechanisms. This covers such things as automatic area change
> and alternative flooding algorithms.  These are extremely dangers.
> They interact very strongly with the basic robustness mechanisms
> of OSPF.  They introduce significant additional complexity in
> many regards.  I strongly suggest that we stay away from any such
> behaviors, and ensure that our charter keeps us away from them.
I do agree stuff like area change etc would be dangerous. Could you point to
the section you are referring for this one? Besides the flooding algos
present in the draft as "Related Solution Methods" can be removed if they
are causing a problem. I do not think there is any mention to using the
methods, just methods used in other protocols that could help in this case.

Thanks,
Vishwas

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Thu, 7 Nov 2002 15:00:48 -0500

Rohit,

> > The problem *was* in the flooding storm that was triggered 
> > in all the failures cited, and the inability to recover.

> We may be talking about different incidents. The one that I 
> was involved in, was a clear implementation mistake 
> (a case was missed) which was the root cause. It should have 
> been caught in testing if somebody had bothered to
> look at why certain LSAs were being generated. The excessive 
> flooding was simply the result.

So we've both observed flooding storms and their bad effects.  They can be started in many different ways, but sometimes bring the network down and take hours or days to recover (that is the problem we want to solve).
 
> I couldn't say this better than Tony/Joel : "at a certain point adding
> more code to an implementation introduces more bugs than the 
> performance gain is worth".  I (like most developers) can attest to this 
> from first hand experience.

I certainly agree with you, Dave, Joel, Tony (thanks all!) that excellent implementation and testing is essential, and that adding complexity and more bugs surely isn't the goal.  I too have experience designing/testing/implementing new routing methods in large-scale applications, and well appreciate these points.  

Summary: We've identified a problem and the problem isn't solved entirely by good implementation/testing/operation, we feel some protocol extensions are necessary.

Thanks,
Regards,
Jerry

---

From: "Choudhury, Gagan L, ALASO" <[email-masked]>
Date: Mon, 11 Nov 2002 12:45:08 -0500

Dennis,
  Thanks for your message and taking the time to read our draft. 

You point out very correctly that adjacencies should not be taken down in the presence of a spike of (non-Hello, not adjacency related) data base traffic (i.e., LSUs).  I suspect that you do it by looking at the OSPF packet header and if you find it to be a Hello then you process it ahead of other packets (LSUs).  This way even if there is a large spike of LSUs, you never miss Hello and keep the adjacency up.  We call this "Prioritized Treatment to Hello Packets".  We are not doubting that you do it but since it is not stated explicitly in OSPF we feel that it is important to explicitly point out the importance of "Prioritizing Hello Packets".  We suggest use of special marking so that Hello packets can be easily separated from LSUs and it would be easy to prioritize them.  However, even without special marking if you can easily separate out Hello packets and process them ahead of LSUs then that is perfectly alright.

We did the simulation study to show what happens if Hellos are processed at the same priority as incoming LSUs (and so can get behind many LSUs under congestion), we did not mean to say "implementations always do this".  In fact we say in the abstract that some implementations are perhaps already prioritizing Hellos in order to not lose adjacency but we want all implementations to do them.

In the simulation as we prioritized Hello we saw that adjacencies were never declared down (as expected).  However, at a larger LSA storm threshold there were a large number of Retransmissions  which caused sustained heavy congestion at a subset of the node processors (the ones with high adjacency). (We used fixed retransmission timer values of 5 seconds or 10 seconds throughout the simulation).  In this case even though links were not being declared down, the sustained heavy congestion due to retransmissions is unacceptable and so we call this a "cliff" even though it is not as harmful as losing adjacencies.  We show by simulations that the retransmission traffic may be reduced significantly (and therefore the "cliff" moved to the right significantly) by prioritizing Acknowledgment packets.  However, this is not necessarily the only solution.  There are beneficial effects of slowing down retransmissions under congestion as well (those simulation results are not reported yet).  Again, we are not saying that implementations do not take any special measures to reduce retransmission traffic under heavy congestion.  However, these special measures are not spelled out explicitly in OSPF but are important enough for explicit mention so that all implementations can benefit from it.

You wondered the cause of the problem or LSA storm (near synchronous update of a very large number of LSAs).  It can be caused by one/more link failures, one/more node failures, sudden synchronization/generation of a large number of LSAs (just by coincidence or even triggered by some software bug or improper operational procedure).  The problem happens very rarely but it does happen.  Also, it is a problem only in large networks with say hundreds of nodes, thousands of trunks, very high adjacency at some nodes, and very large number of LSAs, e.g., large number of ASE LSAs or large number of LSAs that carry link reserved bandwidth information (similar to traffic-engineering LSAs).

                Gagan Choudhury  

-----Original Message-----
From: Dennis Ferguson [mailto:[email-masked]]
Sent: Saturday, November 09, 2002 12:05 AM
To: [email-masked]
Subject: Re: OSPF WG Charter Proposal

Hello,

I just read draft-ietf-ospf-scalability-02.txt, along with
draft-ash-manral-ospf-congestion-control-00.txt which seems
to be related, and find I am made a little uncomfortable by
the way the problem(s) is being described and hence the
inevitability (or even desirability) of the solutions offered.
Please excuse me if this has been discussed before; I skimmed
and deleted a bunch of messages about this before actually
reading the documents and discovering that I cared.

> The various proposals for OSPF Scalability improvements are to move
> the LSA storm threshold (or "cliff") significantly upwards.  Some people
> feel that this should be done only through smart (proprietary)
> implementation.  However, the points against that are the following:

I think the LSA storm threshold, or cliff, is not a problem in itself,
but rather is a symptom of an underlying problem.  Because the problem
was not identified explicitly, however, it took some time to figure out what
might be causing this cliff (guessed at mostly by working backwards from
the proposed solution(s)).  The problem which causes this appears to me to
actually be that the implementation allowed load from non-adjacency-
maintenance traffic (i.e. essentially traffic which wasn't Hellos) to
effect adjacency maintenance, in particular by incorrectly dropping
adjacencies to routers which were in fact still operating.

The problem of erroneously dropping adjacencies to routers which are
still up when under (unrelated) stress is the canonical problem which
leads to network routing collapse.  Just about anyone who has implemented
a link state protocol (or any protocol where adjacencies are maintained
for that matter, e.g. BGP or PPP), deployed it and watched it break a
couple of times knows this by heart, though it is certainly worth writing
down for implementors who haven't got this far yet.  If you want stable
routing then implementations must be done in a way such that this *does*
*not* *happen*, that is the implementation must ensure that the cost of
spikes in database flooding is paid solely by increased convergence time,
and is never the cause of adjacencies being incorrectly declared down.  If
implementations are done this way then the ultimate scalability of the
protocol implementation (beyond data base memory requirements, though
data base memory has gotten inordinately cheap these days) is dictated
solely by how long you are willing to wait for your network to converge
after spikes, and that is a continuous degradation with no "cliff" at all.

Now I would simply assert that there is nothing about the OSPF protocol,
as currently specified, which prevents implementations from achieving the
nirvana described in the previous paragraph.  Nothing.  It may not be
easy to get an implementation to work this way, but I think this difficulty
is inherent in the problem that needs to be solved within the (inherently
proprietary) real-life environment that the implementation runs inside
which sometimes leaves it short of resources, and is hence far removed from
the protocol definition itself.  Errors which cause adjacencies to be
incorrectly declared down are implementation errors, not protocol errors,
and are probably best addressed in the implementation which is broken
rather than the protocol which isn't.  An implementation which doesn't
work like the previous paragraph is one which still has bugs in need
of fixing.

So while I like the simulations done in the scalability draft a lot, I'll
just point out how this draft seems to go given the assumptions
and views above:

(1) You did simulations using an OSPF implemention which had a bug, in
    that it unnecessarily and erroneously declared adjacencies down in
    the presence of a spike of (non-Hello, not adjacency related) data
    base traffic.  How you came to the conclusion that implementations
    which don't make this error are "proprietary" while the particular
    implementation you simulated which made this error is not, I don't
    understand.

(2) Rather than addressing the problem within your implementation, you
    elected to try to solve the problem by having the implementation's
    neighbours help out by setting some new bits in packets (i.e. a
    protocol change) to assist in a prioritization scheme.  I don't
    mind this, except to note that changing an established protocol
    and then waiting for everyone to catch up to the change is usually
    the least productive, longest-term way to fix bugs in an implementation
    which has router neighbours from multiple vendors it is relying on
    to do this for a "fix".

(3) You then redid the simulations after the "fix" was applied, and found
    that while there was still a cliff the "fix" had moved it up and to
    the right.  That is, despite the fact that you even went to the trouble
    of making a protocol change, the "fix" still didn't actually fix the
    problem, which is that you have a cliff at all.  The routing failure can
    apparently still occur, the danger of your network routing melting is
    still there, it just apparently needs a much bigger event to set it
    off.  This is telling me that, independent of this, you really need
    to look at the implementation you are simulating with and determine
    what's actually wrong with it, as it is still an accident waiting to
    happen.

But, more important than this, note that the above comments are still
based on speculation about the root cause of the problem, since according
to the draft the problem is a "cliff" and that the fix is to move the
cliff up and to the right, and it is hard to relate any of this to the
underlying protocol.  You really, really must identify what the routers
are actually doing wrong, in words rather than from numerical simulation
results, since if you don't understand and present this your readers will
never understand the spectrum of possible fixes and why they should work.  For
example, if the problem really is one of routers erroneously dropping
adjacencies where the neighbour is still up, then prioritization of
Hello packet reception and processing seems like not a bad way to help
keep this from occurring (we can debate whether this is better done
by a protocol change or by just having the routers look at the OSPF
packet type before queuing), since its effect is to keep adjacency
errors from occuring by spending CPU keeping this accurate before
spending CPU doing anything which can be deferred.  It is far from
the only way to help, however.  For example, another way to help fix
this (perhaps in addition to the above) might be for the routers to
observe when they've been under load, with a long queue of work to do
that they've perhaps been dropping packets off the end of, and to defer
making any decisions to drop adjacencies until after this condition clears.
This still makes errors about the state of adjacencies, but changes the
nature of the errors from one where the errors you make are terminating
adjacencies which are really still up, which can melt your network, to
one where the errors you make are concluding adjacencies might still be
up when they have in fact gone down, a temporary booboo whose sole effect
might be to increase convergence time (which is how you should be paying
for load spikes in any event).  Note that this adds robustness (i.e.
probably is the best you can do in the circumstance) not only when you
are getting too many LSAs, but also when you are temporarily too short
of CPU to even keep up to the incoming Hellos.

There are a lot of ways to address this particular problem (if this actually
is the "cliff" problem) in implementations, enough that your implementation
really shouldn't have "cliff" problems to begin with, and you should
just keep fixing the implementation until the "cliff" problems go away
so you don't have to live in fear that something big will happen which
will cause your network routing to melt and fail to recover.  This is
so fundamental that I wouldn't wait for the wide deployment of protocol
changes to ensure that this is fixed (even if protocol changes were
exceptionally useful, which I doubt), but would just get it fixed in
the implementations you've already got talking to the other routers you've
already got.

Once you've got basic reliability thing out of the way you can then
begin to look at addressing the real scaling problem which remains, which
is convergence time and maximizing the size of the network you can have
while still having it converge in acceptably short periods.  This is the
problem which I think might benefit from protocol changes, both related
to minimizing flooding load and otherwise.  It is just important to be
clear on why these changes are being done as well, for about the same
reasons it is important to understand what a "cliff" problem is, that
is you'll never get the right answer without being very clear about
why you're doing it.  For example, sending a lot of unnecessary
retransmissions to a neighbour should never, ever cause that neighbour
to break (if it does he's the one with the problem needing fixing), but
it is still not a good thing to do since it makes everyone work harder
and that is guaranteed to slow convergence.  The latter thing is still
very much worth fixing, you just shouldn't be doing the fixing to hack
around implementation-robustness "cliff" problems.

To cut this short, then, I'll just point out what I wanted to say in the
first place about the congestion draft, which is that in general I
don't think using rate controls ever works right given the problem which
I think this should be addressing.  The problem with rate controls is
that if they are fixed configuration they're always wrong, while if
they're automatically adjustable you need to compute adjustments
slowly to ensure stability, which in turn means that the rate you compute
is usually wrong for current circumstances.  It is either too high
or too low.

In the case of flooding to neighbours, both of these cases are bad.
Sending too fast is bad, not because it will break anything (it
absolutely shouldn't) but because processing a big queue of stale
stuff, perhaps with accompanying spurious retransmissions, makes
everyone work harder than they need to and delays convergence.
Sending too slow, however, is also bad because it puts you in
the incredibly silly situation of having an unconverged network where
the routers are simultaneously idle some of the time, which slows
convergence for no discernable advantage at all.  I hence, without
having thought enough about it, like schemes which attempt to do
window control (i.e. limit the number of outstanding, un-acked LSAs
instead), using the delay of and rate at which acks come back as the
control signal, if only because there are examples of transport
protocols working like this which exhibit both stability and a fairly
quick response to changes.

In the case of the SPF computation, however, imposing standardized
rate limits on the maximum frequency with which an implementation may
compute this just seems irrational, and makes no sense at all unless the
implementation entirely lacks the ability to prioritize its actions, an
attribute which is certainly not universal and is unlikely to lead to
great success in making any of this stuff work reliably.  I mean, if
a router is one SPF computation away from converging its routing, and
knows it has absolutely nothing else to do at the moment, is there any
rational reason to require it to sit idle for the four seconds to some
timer expiry before actually doing it?  I think most implementations
should be able to figure out for themselves when it is a good idea to
run the Dykstra and when it isn't, and so should retain the freedom to
do this.

So I think the "congestion" draft has some good ideas (I also like other
attempts to find ways to minimize flooding work) but seems confused about
why these are good ideas which makes some of its other ideas not-so-good,
while the "scalability" draft is proposing a protocol change to relieve
(but not entirely fix) a mysterious problem which, if better defined,
might turn out to be a classic adjacency maintenance implementation bug
which is fixable with no protocol changes at all.  I think the latter
draft would be a whole lot better (in fact, would be really, really
great) if, instead of making a protocol change, you instead did and
documented whatever was necessary to make the "cliff" disappear entirely
from your simulation implementation without making protocol changes,
at which point the (convergence) scaling problem the former draft should
probably be aimed at addressing would be a lot clearer.

Dennis Ferguson