Re: Exit-Graceful Restart Condition

sujay <sujayg@HUAWEI.COM> Mon, 30 May 2005 04:20 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21847 for <ospf-archive@LISTS.IETF.ORG>; Mon, 30 May 2005 00:20:34 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.01067BF5@cherry.ease.lsoft.com>; Mon, 30 May 2005 0:20:29 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73038587 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 00:20:22 -0400
Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Mon, 30 May 2005 00:19:25 -0400
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 <0IHA00GFGBUNOR@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 12:15:59 +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 <0IHA00JGNBUM52@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 12:15:58 +0800 (CST)
Received: from dell60 ([10.18.4.202]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IHA00J0XBYW22@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 May 2005 12:18:33 +0800 (CST)
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Message-ID: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Date: Mon, 30 May 2005 09:43:55 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: sujay <sujayg@HUAWEI.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <42973845.9070404@cisco.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Padma,

Guess we *must* run the dead interval timer on a per neighbor basis,
else
 for the maximum configured dead interval amongst all possible
neighbours.
It could be of course implementation specific.

Solves more than the one issue mentioned in this thread !

Regds,
Sujay

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma
Pillay-Esnault
Sent: Friday, May 27, 2005 8:40 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Exit-Graceful Restart Condition


Kishore Rao wrote:

>----- Original Message -----
>From: "Padma Pillay-Esnault" <ppe@cisco.com>
>To: <OSPF@peach.ease.lsoft.com>
>Sent: Wednesday, May 25, 2005 11:54 AM
>Subject: Re: Exit-Graceful Restart Condition
>
>
>  
>
>>Kishore Rao wrote:
>>
>>    
>>
>>>----- Original Message -----
>>>From: "Acee Lindem" <acee@cisco.com>
>>>To: <OSPF@peach.ease.lsoft.com>
>>>Sent: Wednesday, May 25, 2005 10:10 AM
>>>Subject: Re: Exit-Graceful Restart Condition
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Padma Pillay-Esnault wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>sujay wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Hi All,
>>>>>>
>>>>>>Considering RFC3623, Graceful Restart for OSPF V2 I have a 
>>>>>>problem;
>>>>>>
>>>>>>Ex:
>>>>>>
>>>>>>(network)---- DUT ---- RTA
>>>>>>
>>>>>>(All in the same area)
>>>>>>
>>>>>>Assume DUT undergoes a Graceful-Restart, it sends out grace LSA's 
>>>>>>to RTA and other routers in the 'network'
>>>>>>
>>>>>>At the instant RTA recvs the Grace-LSA it also goes down.
>>>>>>
>>>>>>Is there a way in the RFC 3623 specified as to how DUT could 
>>>>>>Detect this topology change and Exit GR *before* grace period 
>>>>>>expiry??
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>I do not think the RFC covers this case. You are in a double 
>>>>>failure situation.
>>>>>
>>>>>I can think of a simple solution. When DUT reacquires its 
>>>>>router-lsa. It can determine its previous neighbors. It can then 
>>>>>decide that if within DeadRouterInterval that neighbor did not  
>>>>>respond to hellos to abort GR. This would be equivalent to the 
>>>>>normal situation when a router goes down and its
>>>>>neigbors takes DeadInterval to bring down their adjacency
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>I agree completely with Padma. One point, if RTA comes back up and 
>>>>originates a new router LSA then the DUT will detect the 
>>>>inconsistency (as specified in RFC 3623) with it's pre-restart LSA 
>>>>and terminate graceful restart.
>>>>
>>>>
>>>>        
>>>>
>>>Acee,
>>>
>>>Will this work ?
>>>In case there is another router RTB, scan the Hello from RTB for all 
>>>neighbors on the network and then make sure Hello from RTA has been
>>>      
>>>
>received
>  
>
>>>within a Hello interval + 2 (say) . If not, exit GR.
>>>
>>>
>>>      
>>>
>>It is not clear to me. Do you mean that RTB has the same neighbors as 
>>DUT and is on the same network link ?
>>    
>>
>
>Yes.
>  
>

This is not a solution that you can rely one. For one - you can only use

it on a BCAST interface where there are
2+ neighbors possible. It will not work for p2p for example.

I prefer a generic solution.

Padma

>
>  
>
>>Padma
>>
>>    
>>
>>>This would be faster than using the reacquired Router and Network 
>>>LSAs to determine the neighbors, isnt it ?
>>>
>>>Kishore
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>        
>>>>
>>>>>Padma.
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For other routers in the network RTA is still reachable and 
>>>>>>traffic Will be eventually dropped.
>>>>>>
>>>>>>Kindly correct me,
>>>>>>
>>>>>>Regds,
>>>>>>Ashok/Sujay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>
>>>      
>>>
>
>  
>