Subject: [OSPF] Request for a slot in IETF 79

From: "Chen,Huaimo" <[email-masked]>
Date: Tue, 14 Sep 2010 17:51:29 -0400

Hi  Acee,

Could you please allocate a slot for draft
http://datatracker.ietf.org/doc/draft-chen-ospf-intelligent-db-exch/ in IETF
79?

Best Regards,

Huaimo

---

From: Acee Lindem <[email-masked]>
Date: Thu, 16 Sep 2010 13:36:25 -0400

Hi Huaimo,
Sure - we'll put you down for a slot. One question that you should be able to answer, is precisely what problem you are solving with this optimization.
Thanks,
Acee

On Sep 14, 2010, at 5:51 PM, Chen,Huaimo wrote:

Hi  Acee,

Could you please allocate a slot for draft http://datatracker.ietf.org/doc/draft-chen-ospf-intelligent-db-exch/ in IETF 79?

Best Regards,
Huaimo
<ATT00001..txt>

---

From: "Chen,Huaimo" <[email-masked]>
Date: Thu, 16 Sep 2010 15:44:29 -0400

Hi Acee,

    Thank you very much for assigning me a slot!
    The problem we are going to solve with this optimization is about
performance in some situations.

Best Regards,
Huaimo
-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Thursday, September 16, 2010 1:36 PM
To: Huaimo Chen
Cc: [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Hi Huaimo,
Sure - we'll put you down for a slot. One question that you should be able
to answer, is precisely what problem you are solving with this optimization.
Thanks,
Acee

Hi  Acee,

Best Regards,
Huaimo
<ATT00001..txt>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 16 Sep 2010 16:46:12 -0400

Hi Huaimo,

> performance in some situations.

Which situations? As Peter pointed out, it doesn't work as is. If it is possible at all, making it work will require considerably more complexity. 

Thanks,
Acee

---

From: Peter Psenak <[email-masked]>
Date: Thu, 16 Sep 2010 22:22:06 +0200

Chen,

you assume that when routers are reachable at the time they form 
adjacency their LS databases are equal. Unfortunately that is not 
guaranteed.

Taking the figure (1) from your draft, imagine N1 goes down. RT1 floods 
it's changed LSA to RT2, RT3 and RT4. RT4 can not flood RT1's LSA to 
RT5, because the link between RT4 and RT5 is having problems. Before the 
adjacency between RT4 and RT5 goes down, adjacency between RT3 and RT6 
is formed without any exchange as proposed in the draft, because they 
are still reachable via the original topology. As a result RT6 would not 
get the latest version of the RT1's LSA.

Same applies to the idea of using the time difference. There is no 
guarantee that the other side has the latest version of all LSAs.

thanks,
Peter

Chen,Huaimo wrote:
> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: "Chen,Huaimo" <[email-masked]>
Date: Fri, 17 Sep 2010 09:31:38 -0400

Hi Peter,

    Thanks much for your email!
    The problem you mentioned can be simply fixed by the following changes
in the draft:
    (1) When building the neighbor summary list, the local router puts the
LSAs that are changed within a given time if it is reachable to the
neighboring router.
    (2) Remove the changes in the draft for processing of DD packet
contents.

Best Regards,
Huaimo

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Thursday, September 16, 2010 4:22 PM
To: Chen,Huaimo
Cc: 'Acee Lindem'; [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Chen,

thanks,
Peter

---

From: Acee Lindem <[email-masked]>
Date: Fri, 17 Sep 2010 09:43:26 -0400

Hi Huaimo,
It still doesn't work. There is no way you can guarantee LSAs in your database aren't stuck on a retransmission list somewhere between the router building the summary list and new neighbor. The only case that works for certain is if you already have a connection to this neighbor in the same area - then you only need to include LSAs on your retransmission list to the parallel neighbor adjacency.  This special case doesn't seem to interesting since parallel OSPF adjacencies aren't very common given all the layer two link bundling mechanisms.  

Are you sure you want to present this draft? You also didn't answer my question of what problem you are trying to solve? 

Thanks, 
Acee

---

From: "Chen,Huaimo" <[email-masked]>
Date: Fri, 17 Sep 2010 13:57:58 -0400

Hi Acee,

    You mentioned a retransmission list. Is this retransmission list the one
between RT4 and RT5 as indicated by Peter (where new version of RT1's LSA
can not go through the link between RT4 and RT5 since there is a problem
there)? 

    I am sure I would like to present the draft.

    The problem we are going to solve with this optimization is about
performance in some situations. 
    In the case that there is a large link state database (for example in
RT3 and RT6 in figure 1, assumed), and the link between two routers such as
RT3 and RT4 is down and up repeatedly for some time, the establishment of
the full adjacency between these two routers will be repeated as the link
down and up and will use lots of resources such as CPU on the two routers,
which may affect the other applications running on these two routers. 

Best Regards,
Huaimo

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Friday, September 17, 2010 9:43 AM
To: Chen,Huaimo
Cc: Peter Psenak; [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Hi Huaimo,
It still doesn't work. There is no way you can guarantee LSAs in your
database aren't stuck on a retransmission list somewhere between the router
building the summary list and new neighbor. The only case that works for
certain is if you already have a connection to this neighbor in the same
area - then you only need to include LSAs on your retransmission list to the
parallel neighbor adjacency.  This special case doesn't seem to interesting
since parallel OSPF adjacencies aren't very common given all the layer two
link bundling mechanisms.  

Are you sure you want to present this draft? You also didn't answer my
question of what problem you are trying to solve? 

Thanks, 
Acee

---

From: Dave Katz <[email-masked]>
Date: Sun, 19 Sep 2010 00:10:40 -0600

This stuff is rife with race conditions.  And the mechanism *must* be absolutely perfect, because OSPF lacks any mechanism (other than flapping the whole adjacency) to bring two out-of-sync nodes back to synchronization--there's no plan B to clean up any stragglers from imperfections in plan A, nor any way to discover that plan B was needed.  (In IS-IS you have the CSNP, which can be ultimately used to cure all such ills.)

Trying to do anything like this when the neighbor is unreachable is doomed--if the neighbor is unreachable, it means that the network is partitioned, and you can't make any useful assumptions about the neighbor's database contents at that point.  And trying to make decisions based on the time an LSA was received is equally doomed, because (particularly in that partition case) your receive time tells you almost nothing about the LSA's presence or lack thereof somewhere else, or when it might have arrived there if it did.  It can only tell you in very rough terms when it was generated, and only if it is not a do-not-age LSA.  So I believe that you cannot correlate neighbor reachability time and LSA receive time, or at least not well enough to achieve perfection.

If I understand correctly, your mechanism is fundamentally relying on synchronization by transitivity--"I'm synchronized with you because you're synchronized with someone else, who through a long enough chain is synchronized to me."  This is true when it is true, but alas it is not always true.

Here's one fun failure case: if the network happens to partition (by definition somewhere else) at roughly the same time you're trying to establish the new adjacency (thus healing the adjacency, though you don't know that), you are practically guaranteed to lose LSAs.  As long as the intelligent exchange thing terminates before the LSAs describing the partition show up, you will lose, since your neighbor will remain reachable at all times.  Since the whole point of the intelligent exchange is to speed the establishment, the probability of this occurring is much higher.

Of course this becomes much more evil if that old partition heals and the intelligent exchange thing happens there (which it sounds like it would)--the databases cannot ever be teased into matching, and the protocol will never know.

These problems are really hard, and really subtle.

--Dave

On Sep 16, 2010, at 2:22 PM, Peter Psenak wrote:

> Chen,
> 
> you assume that when routers are reachable at the time they form adjacency their LS databases are equal. Unfortunately that is not guaranteed.
> 
> Taking the figure (1) from your draft, imagine N1 goes down. RT1 floods it's changed LSA to RT2, RT3 and RT4. RT4 can not flood RT1's LSA to RT5, because the link between RT4 and RT5 is having problems. Before the adjacency between RT4 and RT5 goes down, adjacency between RT3 and RT6 is formed without any exchange as proposed in the draft, because they are still reachable via the original topology. As a result RT6 would not get the latest version of the RT1's LSA.
> 
> Same applies to the idea of using the time difference. There is no guarantee that the other side has the latest version of all LSAs.
> 
> thanks,
> Peter
> 
> 
> Chen,Huaimo wrote:
>> Hi Acee,
>> From: Acee Lindem [mailto:[email-masked]] Sent: Thursday, September 16, 2010 1:36 PM
>> To: Huaimo Chen
>> Cc: [email-masked]

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 19 Sep 2010 09:59:54 -0500 (CDT)

Hi Dave

Would it be fair to conclude that reachability in SPT is no guarantee of synchronized databases. If such an assumption is made and adjacency is declared with no database exchange, any mismatch in the databases of adjacent routers may persist for long times (until the missing LSAs are refreshed).

Thanks
Mukul

----- Original Message -----
From: "Dave Katz" <[email-masked]>
To: "Huaimo Chen" <[email-masked]>
Cc: "[email-masked] List" <[email-masked]>
Sent: Sunday, September 19, 2010 1:10:40 AM
Subject: Re: [OSPF] Request for a slot in IETF 79

--Dave

---

From: "Chen,Huaimo" <[email-masked]>
Date: Sun, 19 Sep 2010 11:22:05 -0400

Hi Dave,

    Can you give some more details about the fun failure case? It seems that
the fix for the problem that Peter mentioned may solve this case.

Best Regards,
Huaimo

-----Original Message-----
From: Dave Katz [mailto:[email-masked]] 
Sent: Sunday, September 19, 2010 2:11 AM
To: Chen,Huaimo
Cc: [email-masked] List; Peter Psenak
Subject: Re: [OSPF] Request for a slot in IETF 79

This stuff is rife with race conditions.  And the mechanism *must* be
absolutely perfect, because OSPF lacks any mechanism (other than flapping
the whole adjacency) to bring two out-of-sync nodes back to
synchronization--there's no plan B to clean up any stragglers from
imperfections in plan A, nor any way to discover that plan B was needed.
(In IS-IS you have the CSNP, which can be ultimately used to cure all such
ills.)

Trying to do anything like this when the neighbor is unreachable is
doomed--if the neighbor is unreachable, it means that the network is
partitioned, and you can't make any useful assumptions about the neighbor's
database contents at that point.  And trying to make decisions based on the
time an LSA was received is equally doomed, because (particularly in that
partition case) your receive time tells you almost nothing about the LSA's
presence or lack thereof somewhere else, or when it might have arrived there
if it did.  It can only tell you in very rough terms when it was generated,
and only if it is not a do-not-age LSA.  So I believe that you cannot
correlate neighbor reachability time and LSA receive time, or at least not
well enough to achieve perfection.

If I understand correctly, your mechanism is fundamentally relying on
synchronization by transitivity--"I'm synchronized with you because you're
synchronized with someone else, who through a long enough chain is
synchronized to me."  This is true when it is true, but alas it is not
always true.

Here's one fun failure case: if the network happens to partition (by
definition somewhere else) at roughly the same time you're trying to
establish the new adjacency (thus healing the adjacency, though you don't
know that), you are practically guaranteed to lose LSAs.  As long as the
intelligent exchange thing terminates before the LSAs describing the
partition show up, you will lose, since your neighbor will remain reachable
at all times.  Since the whole point of the intelligent exchange is to speed
the establishment, the probability of this occurring is much higher.

Of course this becomes much more evil if that old partition heals and the
intelligent exchange thing happens there (which it sounds like it
would)--the databases cannot ever be teased into matching, and the protocol
will never know.

--Dave

On Sep 16, 2010, at 2:22 PM, Peter Psenak wrote:

> Chen,
> 
> you assume that when routers are reachable at the time they form adjacency
their LS databases are equal. Unfortunately that is not guaranteed.
> Taking the figure (1) from your draft, imagine N1 goes down. RT1 floods
it's changed LSA to RT2, RT3 and RT4. RT4 can not flood RT1's LSA to RT5,
because the link between RT4 and RT5 is having problems. Before the
adjacency between RT4 and RT5 goes down, adjacency between RT3 and RT6 is
formed without any exchange as proposed in the draft, because they are still
reachable via the original topology. As a result RT6 would not get the
latest version of the RT1's LSA.

---

From: Peter Psenak <[email-masked]>
Date: Sun, 19 Sep 2010 19:11:34 +0200

Huaimo,

> the fix for the problem that Peter mentioned may solve this case.

no, unfortunately the fix will not work. As others have alluded to, 
there are way too many cases where the mechanism you are proposing would 
simply not work.

thanks,
Peter

---

From: "Chen,Huaimo" <[email-masked]>
Date: Sun, 19 Sep 2010 13:47:02 -0400

Hi Peter,

    Can you give some more details that illustrates that the fix does not
work for your case/problem you mentioned?

Best Regards,
Huaimo

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Sunday, September 19, 2010 1:12 PM
To: Chen,Huaimo
Cc: 'Dave Katz'; [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Huaimo,

thanks,
Peter

>> you assume that when routers are reachable at the time they form
adjacency

---

From: Peter Psenak <[email-masked]>
Date: Sun, 19 Sep 2010 21:44:15 +0200

Huaimo,

you try to fix the fundamental problem with timer approach. There is no 
bound on how long can LSA sit on the retransmission list, nor is there 
an interval that can guarantee that the neighbor you are bringing the 
adjacency with has the LSA in it's database. Simply put - timer approach 
does not work.

thanks,
Peter

---

From: "Chen,Huaimo" <[email-masked]>
Date: Sun, 19 Sep 2010 17:56:16 -0400

Hi Peter,

    Regarding to the time that LSA can sit on the retransmission list, why
is there no bound? If LSA can not get through the link that you mentioned
that causes the LSA can not get through for a un-bound time (while sitting
on the retransmission list), then HELLO may not get through over the link,
the adjacency over the link may go down and the retransmission list may be
cleaned.

Best Regards,
Huaimo

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Sunday, September 19, 2010 3:44 PM
To: Chen,Huaimo
Cc: 'Dave Katz'; [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Huaimo,

thanks,
Peter

---

From: Ross Callon <[email-masked]>
Date: Sun, 19 Sep 2010 22:12:28 -0400

I am suspecting that if several of us were to come up with failure scenarios, then Dave's failure scenario might be slightly different from my failure scenario, which might be slightly different from another person's failure scenario.

There would presumably be some similarities: If routers A and B open an adjacency, then if their databases are identical at the time that the link between them first comes up then we wouldn't have a problem. Thus the issue comes up: Why would their databases be different even though a Dijkstra computation shows that there is some other path between them? The obvious reason is that there are LSAs in transit, and some routers have gotten them and some haven't (yet). Then something else would need to fail to prevent routers A and B from eventually becoming synchronized over the alternate route between them. However, there is room for a lot of flexibility in terms of what might fail, how it fails, and if several things fail in what combination and what order (and when some of them might or might not recover). Also, if A and B announce the link between them (possibly before they become synchronized), then another link could recover elsewhere in the network, and the routers at each end of that link could see a path between them via which includes the link from A to B, and decide that they don't need to do database synch either (not knowing that A and B never got fully in synch). 

If a network were to deploy the changes in draft-chen-ospf-intelligent-db-exch, then the complexity of various possible failure scenarios strikes me as hopeless to try to fully comprehend. 
	
Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chen,Huaimo
Sent: Sunday, September 19, 2010 11:22 AM
To: Dave Katz
Cc: [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Hi Dave,

Best Regards,
Huaimo

-----Original Message-----
From: Dave Katz [mailto:[email-masked]] 
Sent: Sunday, September 19, 2010 2:11 AM
To: Chen,Huaimo
Cc: [email-masked] List; Peter Psenak
Subject: Re: [OSPF] Request for a slot in IETF 79

--Dave

---

From: Dave Katz <[email-masked]>
Date: Sun, 19 Sep 2010 20:44:14 -0600

On Sep 19, 2010, at 8:59 AM, Mukul Goyal wrote:

> Hi Dave
> 
> Would it be fair to conclude that reachability in SPT is no guarantee of synchronized databases.

This is most decidedly true.

> If such an assumption is made and adjacency is declared with no database exchange, any mismatch in the databases of adjacent routers may persist for long times (until the missing LSAs are refreshed).

Yep.

--Dave

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 19 Sep 2010 21:48:08 -0500 (CDT)

I guess it is important to add that OSPF-OR approach (for extending OSPF to MANETs; RFC 5820) does allow the use of "unsynchronized adjacencies" in routing table calculations but requires that an explicit database exchange be done on such an adjacency if the two ends are no longer reachable in the SPT built after excluding all links with unsynchronized adjacencies.

Thanks
Mukul

----- Original Message -----
From: "Ross Callon" <[email-masked]>
To: "Huaimo Chen" <[email-masked]>, "Dave Katz" <[email-masked]>
Cc: [email-masked]
Sent: Sunday, September 19, 2010 9:12:28 PM
Subject: Re: [OSPF] Request for a slot in IETF 79

There would presumably be some similarities: If routers A and B open an adjacency, then if their databases are identical at the time that the link between them first comes up then we wouldn't have a problem. Thus the issue comes up: Why would their databases be different even though a Dijkstra computation shows that there is some other path between them? The obvious reason is that there are LSAs in transit, and some routers have gotten them and some haven't (yet). Then something else would need to fail to prevent routers A and B from eventually becoming synchronized over the alternate route between them. However, there is room for a lot of flexibility in terms of what might fail, how it fails, and if several things fail in what combination and what order (and when some of them might or might not recover). Also, if A and B announce the link between them (possibly before they become synchronized), then another link could recover elsewhere in the network, and the routers at each
  end of that link could see a path between them via which includes the link from A to B, and decide that they don't need to do database synch either (not knowing that A and B never got fully in synch). 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chen,Huaimo
Sent: Sunday, September 19, 2010 11:22 AM
To: Dave Katz
Cc: [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Hi Dave,

Best Regards,
Huaimo

-----Original Message-----
From: Dave Katz [mailto:[email-masked]] 
Sent: Sunday, September 19, 2010 2:11 AM
To: Chen,Huaimo
Cc: [email-masked] List; Peter Psenak
Subject: Re: [OSPF] Request for a slot in IETF 79

--Dave

---

From: Dave Katz <[email-masked]>
Date: Sun, 19 Sep 2010 20:55:01 -0600

That pretty well sums it up.

The fundamental issue is that LS protocols are guaranteed to converge precisely because the databases *are* synchronized when the adjacency comes up.  Everything else comes from that (and race conditions are corrected, etc.)

If you skip this step, you've cut out the underpinnings of the protocol in a really primary sort of way.

Now one could claim that the failure modes are "unlikely" (requiring multiple failures within rather narrow time frames) but even if failure is unlikely, that doesn't cut it...

--Dave

---

From: Dave Katz <[email-masked]>
Date: Sun, 19 Sep 2010 20:59:59 -0600

This makes sense, I think.  If I understand correctly, the protocol treats such adjacencies as "suspect" and essentially requires a connected topology via known-good adjacencies.  This deals with the partition race condition because ultimately the bailout clause will kick in (since the "unsynchronized adjacency" won't count...)

See earlier comment about "hard" and "subtle".  ;-)

--Dave

---

From: Peter Psenak <[email-masked]>
Date: Mon, 20 Sep 2010 08:20:12 +0200

Huaimo,

not really. You can get a link where small Hellos are getting through, 
but larger updates are not, so you can not correlate one with the other.

thanks,
Peter

---

From: mike shand <[email-masked]>
Date: Mon, 20 Sep 2010 09:43:05 +0100

> Now one could claim that the failure modes are "unlikely" (requiring multiple failures within rather narrow time frames) but even if failure is unlikely, that doesn't cut it...

This really is the issue here. This draft is extremely dangerous because 
it is breaking these fundamental design principles of the link state 
update process. It is critically important that this processes is 
unconditionally correct in the presence of ANY perturbation (probable or 
improbable) and that the system should return (in the steady state) to 
complete synchronization.

Getting this right is non-trivial, and any attempt to infer information 
about synchronization from the results of the SPF (which in turn is 
dependent on the synchronization) is doomed to failure.

A long time ago the IS-IS update process was proved (by someone much 
smarter than me, using temporal logic and such like)  to be logically 
correct and this probably applies also to the OSPF update process since 
they are essentially the same.

In fact the generation of the proof revealed one VERY obscure case where 
it was not correct, but that was subsequently fixed.

I would suggest that any attempt to change the fundamentals of the 
update process in this manner would need to be subject to such rigorous 
analysis.

I would also suggest that the "optimization" is not worth pursuing.

This seems like a non-problem.

     Mike

>> There would presumably be some similarities: If routers A and B open an adjacency, then if their databases are identical at the time that the link between them first comes up then we wouldn't have a problem. Thus the issue comes up: Why would their databases be different even though a Dijkstra computation shows that there is some other path between them? The obvious reason is that there are LSAs in transit, and some routers have gotten them and some haven't (yet). Then something else would need to fail to prevent routers A and B from eventually becoming synchronized over the alternate route between them. However, there is room for a lot of flexibility in terms of what might fail, how it fails, and if several things fail in what combination and what order (and when some of them might or might not recover). Also, if A and B announce the link between them (possibly before they become synchronized), then another link could recover elsewhere in the network, and the routers at ea
>   ch end of that link could see a path between them via which includes the link from A to B, and decide that they don't need to do database synch either (not knowing that A and B never got fully in synch).

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri

---

From: "Chen,Huaimo" <[email-masked]>
Date: Mon, 20 Sep 2010 20:54:35 -0400

Hi Peter,

    If a hello packet can get through the link at least once in every dead
interval, but a LSA update can not get through the link for a un-bounded
time because the size of a hello packet is smaller than the size of a LSA
update packet, then can we say that there are bugs on the router sending
these packets?

Best Regards,
Huaimo 

-----Original Message-----
From: Peter Psenak [mailto:[email-masked]] 
Sent: Monday, September 20, 2010 2:20 AM
To: Chen,Huaimo
Cc: 'Dave Katz'; [email-masked]
Subject: Re: [OSPF] Request for a slot in IETF 79

Huaimo,

thanks,
Peter

>>> it's changed LSA to RT2, RT3 and RT4. RT4 can not flood RT1's LSA to
RT5,
>>> adjacency between RT4 and RT5 goes down, adjacency between RT3 and RT6
is
>>>>> http://datatracker.ietf.org/doc/draft-chen-ospf-intelligent-db-exch/
in
>>> IETF

---

From: Dave Katz <[email-masked]>
Date: Mon, 20 Sep 2010 23:37:45 -0400

This is beside the point;  the fact is that the mechanism fundamentally cannot work in a robust fashion.  This has been pointed out by two of the designers of IS-IS, along with one grumpy old guy that has implemented both IS-IS and OSPF (and has been around OSPF since it was pronounced "ospee figpee").

I believe that the basic flaw in the design has been spelled out.  If you really believe that adjacency bringup needs to be optimized, you need to come up with a design that addresses this flaw (and doesn't introduce others.)

--Dave

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 21 Sep 2010 09:34:06 +0530

Huaimo,

Most service grade routers would prioritize the Hellos over the LS update packets and there a very high chance, that while you may be able to process the Hellos within the dead interval, you may miss out processing your LS Updates. Its just how the routers are designed and its got nothing to do with the packet size.

Cheers, Manav

> Sent: Tuesday, September 21, 2010 6.25 AM
> To: 'Peter Psenak'
> Cc: [email-masked]
> >>>     Can you give some more details about the fun failure 
> case? It seems
> >> that
> >>> (In IS-IS you have the CSNP, which can be ultimately used 
> to cure all
> > such
> >>> ills.)
> >>>
> >>> database contents at that point.  And trying to make 
> decisions based on
> >> the
> >>> time an LSA was received is equally doomed, because 
> (particularly in
> that
> >>> partition case) your receive time tells you almost 
> nothing about the
> > LSA's
> >>> presence or lack thereof somewhere else, or when it might 
> have arrived
> >> there
> >>> correlate neighbor reachability time and LSA receive 
> time, or at least
> > not
> >>> synchronization by transitivity--"I'm synchronized with 
> you because
> > you're
> >>> establish the new adjacency (thus healing the adjacency, 
> though you
> don't
> >>> at all times.  Since the whole point of the intelligent 
> exchange is to
> >> speed
> >>> Of course this becomes much more evil if that old 
> partition heals and
> the
> >>> formed without any exchange as proposed in the draft, 
> because they are
> >> still
> >>>>> Sure - we'll put you down for a slot. One question that 
> you should be
> >>> able