Re: draft-kou-ospf-immediately-replying-hello-00.txt

Zengjie Kou <kouzengjie@HUAWEI.COM> Fri, 24 February 2006 10:05 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZph-0000Z7-Lf for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 05:05:53 -0500
Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZph-0005Ar-E5 for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 05:05:53 -0500
Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00034CEE@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 5:05:52 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100269956 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 05:05:52 -0500
Received: from 57.66.76.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 05:05:52 -0500
Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600MJSQWXFY@lhrga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 09:41:22 +0000 (GMT)
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 <0IV600IWWRY4Z3@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:03:40 +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 <0IV600DUSRY4N3@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:03:40 +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 <0IV600M73S73GA@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:09:04 +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: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com>
Message-ID: <000701c63928$9908e590$610c6f0a@china.huawei.com>
Date: Fri, 24 Feb 2006 17:56:35 +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: 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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5

Hi, Acee
   The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up.
I agree this. However, when an normal interface whose state is up goes down then up, immediate hello  is  effective by avoiding 
helloInterval or backupSeen.

Thanks,
Zengjie
 
----- Original Message ----- 
From: "Acee Lindem" <acee@CISCO.COM>
To: <OSPF@PEACH.EASE.LSOFT.COM>
Sent: Thursday, February 23, 2006 5:41 AM
Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt


> Zengjie Kou wrote:
> 
>>Hi, Acee,
>>    You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed.
>>  
>>
> Hi Zengjie,
> 
> Speaking strictly in terms of state machines, it seems the interface 
> would lose it's DR/BDR state
> when it goes down (and cannot send a hello). Wouldn't this scenario be 
> better handled
> by the empty hello many OSPF implementations send when an interface 
> first comes up?
> 
> Thanks,
> Acee
> 
>>Thanks,
>>Zengjie
>>
>>----- Original Message ----- 
>>From: "Acee Lindem" <acee@CISCO.COM>
>>To: <OSPF@PEACH.EASE.LSOFT.COM>
>>Sent: Monday, February 20, 2006 11:15 PM
>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt
>>
>>
>>  
>>
>>>Hi Zengjie,
>>>
>>>Zengjie Kou wrote:
>>>
>>>    
>>>
>>>>Hi,Acee,
>>>>   If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello.
>>>> 
>>>>
>>>>      
>>>>
>>>This is only when the DR/BDR knows that it is going down or the case 
>>>where the router
>>>priority is set to 0.
>>>
>>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR
>>>so I don't see how it helps.
>>>
>>>Thanks,
>>>Acee
>>>
>>>    
>>>
>>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen.
>>>>Namely, improving convergence.
>>>>
>>>>Thanks a lot,
>>>>Zengjie
>>>>
>>>>----- Original Message ----- 
>>>>From: "Acee Lindem" <acee@CISCO.COM>
>>>>To: <OSPF@PEACH.EASE.LSOFT.COM>
>>>>Sent: Saturday, February 18, 2006 5:17 AM
>>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt
>>>>
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>>>Hi Zengjie,
>>>>>
>>>>>Under what situations does having the router who changed to/from
>>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election
>>>>>is a distributed algorithm dependent on the calculating routers state, it
>>>>>seems this won't help in all that many cases.
>>>>>
>>>>>Thanks,
>>>>>Acee
>>>>>   
>>>>>
>>>>>        
>>>>>
>>>> 
>>>>
>>>>      
>>>>
>>
>>  
>>