Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

[Paul Jakma <[e-mail]>]

Hi,

On Thu, 29 Dec 2005, Kouzengjie wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> The draft can be found here:
> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt

GNU Zebra's (and hence Quagga's) ospfd has done something like this 
for a long time now (a subset at least, send hello immediately if 
neighbour state changes into state Init).

One thing, might it be an idea to specify that the Immediate Hello be 
/independent/ of the Hello-Interval timer? (ie dont set or reset the 
interface's Hello timer because of any Immediate Hello sent). 
Otherwise, there'll be strong tendency for the HelloInterval timers 
across routers to latch. Not sure how much this matters.

Also, it might be an idea to add some state (e.g. a delay factor, 
some arbitrary protocol constant, 100ms or somesuch) to prevent 
Immediate-Hello storms if, for whatever reason, neighbour states fail 
to progress pass ExStart and fall back to Init. Some types of links 
are quite sensitive to L2 congestion for example.

6.1.1. Is there a good reason why pre-2-Way Immediate-Hellos are to 
be sent unicast?

If you happen to process multiple neighbour state changes (e.g. 
because of the delay factor on a previous immediate hello, or because 
the implementation chooses to define 'immediate' as 'very small 
delay'), one Immediate-Hello to AllSPFRouters can take care of all of 
them - rather than having to send multiple unicast hellos to each 
neighbour.

I.e. it might be an idea to just drop the modifications proposed in 
6.1.1.

regards,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
  Earth men are real men!