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

Zengjie Kou <kouzengjie@HUAWEI.COM> Wed, 04 January 2006 02:00 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etxwa-0000cJ-5D for ospf-archive@megatron.ietf.org; Tue, 03 Jan 2006 21:00:04 -0500
Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19720 for <ospf-archive@LISTS.IETF.ORG>; Tue, 3 Jan 2006 20:58:48 -0500 (EST)
Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00008698@wildebeest.ease.lsoft.com>; Tue, 3 Jan 2006 20:59:31 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95399850 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Jan 2006 20:59:31 -0500
Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 3 Jan 2006 20:59:30 -0500
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISJ00M8RPS1P2@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:04:49 +0800 (CST)
Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISJ006B8PS0JV@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:04:49 +0800 (CST)
Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISJ00J2FQ03OF@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:09:39 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> <Pine.LNX.4.63.0512311434400.11084@sheen.jakma.org>
Message-ID: <000d01c610d2$61a11100$610c6f0a@china.huawei.com>
Date: Wed, 04 Jan 2006 09:58:38 +0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Zengjie Kou <kouzengjie@HUAWEI.COM>
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
List-Help: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>, <mailto:LISTSERV@PEACH.EASE.LSOFT.COM?body=INFO+OSPF>
List-Unsubscribe: <mailto:OSPF-unsubscribe-request@PEACH.EASE.LSOFT.COM>
List-Subscribe: <mailto:OSPF-subscribe-request@PEACH.EASE.LSOFT.COM>
List-Owner: <mailto:OSPF-request@PEACH.EASE.LSOFT.COM>
List-Archive: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>
Content-Transfer-Encoding: 7bit

----- Original Message ----- 
From: "Paul Jakma" <paul@CLUBI.IE>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Sunday, January 01, 2006 12:05 AM
Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]


> 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.
>
Yes, Immediate Hello is independent of HelloInterval timer.
It is in favor of compatibility.
 
> 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.
> 
Yes, this may be a good idea. We consider that it is a option of Immediate Hello.


> 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.
> 
If Immediate Hello is multicast, all routers attached the ospf networks will handle
all Immediate hellos,which consumes lots of cost. So, unicast is an appropriate mechanism 
which finishes all in the peer of sending hello.


Thanks
Kou.

> regards,
> -- 
> Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
> Fortune:
>  Earth men are real men!