Avi:

 As Curtis already explained, OSPF data is NOT preserved, but
 recollected from the neighbors. That's why we go through the
 LSDB resync process.

Alex.

> Some people would rather have any effort available expended towards
> good software (or a real OS, if that crutch is needed). I can see
> bringing back BGP quickly, but the disasters possible with crunched
> OSPF data are soooo much worse. 80k routes causing cyclic crashing
> and propagation, anyone?

> Avi

>>
>> alex:
>>
>> I hope it is clear by now that nobody is trying to solve OSPF
>> bugs leading to crashes with additional mechanisms in the protocol.
>>
>> However, realistically speaking, SW will always have bugs, and
>> the question is how one would like to react on a crash. If you
>> want the process to remain down---no mechanisms are required.
>> If some people want to try to bring it back up there definitely
>> are people who want to do it without resetting the forwarding
>> state.
>>
>> Alex.
>>
>>
>>
>> >> Or this way: would you not like your router to at least try to
>> >> bring the process that has just crashed back up with (of course,
>> >> with an oscillation prevention mechanism)?
>>
>> > How about starting by not having the process/router crash to begin with?
>> > That would solve 99% of the problems that you are trying to address.
>>
>> >> > Case B is even more interesting. The software crashed. Ok, so now I'm
>> >> > supposed to believe that crashing software can be fixed by adding MORE
>> >> > software and protocol extentsions, even though the original software
>> >> > didn't work well enough not to crash in the first place? Essentially my
>> >> > take on this is: I couldn't write robust software, so let me make the
>> >> > system more robust by adding more software!
>> >>
>> >> Following your logic here we would probably have to remove
>> >> protected memory support from all CPUs and OSes and have all programmers
>> >> fix all their bugs in all their programs... Oh, dear...
>>
>> > Page fault caused by de-referrencing a virtual address while running in a
>> > state that can be pre-empted is very very very different from a page fault
>> > caused by a process that does not pay attention to the heap boundaries...
>>
>>
>> > Alex
>>
>>
>>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]