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

Acee Lindem <acee@CISCO.COM> Tue, 28 February 2006 12:34 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE441-0002u7-Gv for ospf-archive@LISTS.IETF.ORG; Tue, 28 Feb 2006 07:34:49 -0500
Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE441-0001G4-67 for ospf-archive@LISTS.IETF.ORG; Tue, 28 Feb 2006 07:34:49 -0500
Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00038998@wildebeest.ease.lsoft.com>; Tue, 28 Feb 2006 7:34:46 -0500
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100595038 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 07:34:46 -0500
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 28 Feb 2006 07:34:46 -0500
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2006 07:34:45 -0500
X-IronPort-AV: i="4.02,152,1139202000"; d="scan'208"; a="83233447:sNHT34642456"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1SCYjqM012532 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 28 Feb 2006 07:34:45 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 07:34:45 -0500
Received: from [10.82.240.144] ([10.82.240.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 07:34:45 -0500
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
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> <000701c63928$9908e590$610c6f0a@china.huawei.com> <43FF13BB.9030903@cisco.com> <000801c63c19$3121b760$610c6f0a@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Feb 2006 12:34:45.0070 (UTC) FILETIME=[5AE00EE0:01C63C63]
Message-ID: <44044364.30701@cisco.com>
Date: Tue, 28 Feb 2006 07:34:44 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Acee Lindem <acee@CISCO.COM>
Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000801c63c19$3121b760$610c6f0a@china.huawei.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: ff0adf256e4dd459cc25215cfa732ac1

Zengjie Kou wrote:

>Hi, Acee
>    On p2p networks, there is no distinction between first coming or coming back up. The immediate hello is efficient in discover neighbors and convergence.
>    On broadcast networks, when an interface first coming, DR election need to wait  wait-time. However, when an interface coming back up, DR election need not to wait wait-time(if BDR exists or the down interface is not DR). Here, only HelloInterval or     BackupSeen is needed to discover neighbor or convergence. Immediate hello avoids the HelloInterval or backupSeen on the case.
>  
>
Hi Zengjie,

I think you're saying the hello when the DR/BDR interface state changes 
is solely for
the case when the BDR's interface flaps. Correct?

     BDR Interface goes down
     Ex-BDR Interface comes back up
     Ex-BDR send initial hello ----------------------------> Other 
Routers on LAN
     Ex-BDR goes to 2-way <----------------------------   Other Routers 
Immediate reply
                                                                                          
New DR/BDR election
     Triggers election on  Ex-BDR  <----------------------   New DR/BDR 
send hello

Why not just process the neighbor change event before sending the 
immediate reply?
In other words, perform the new DR/BDR election before the immediate 
reply hello?
                   
Thanks,
Acee

>Thanks,
>Zengjie
> 
> 
>----- Original Message ----- 
>From: "Acee Lindem" <acee@CISCO.COM>
>To: <OSPF@PEACH.EASE.LSOFT.COM>
>Sent: Friday, February 24, 2006 10:10 PM
>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt
>
>
>  
>
>>Zengjie Kou wrote:
>>
>>    
>>
>>>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.
>>> 
>>>
>>>      
>>>
>>Hi Zengjie,
>>
>>I don't think there should be a distinction between first coming or 
>>coming back up.
>>
>>Thanks,
>>Acee
>>
>>    
>>
>>>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
>>>>>>>> 
>>>>>>>>
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>> 
>>>
>>>      
>>>
>
>  
>