Re: Exit-Graceful Restart Condition

Acee Lindem <acee@CISCO.COM> Tue, 31 May 2005 22:29 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 SAA06031 for <ospf-archive@LISTS.IETF.ORG>; Tue, 31 May 2005 18:29:53 -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 <13.01069FF9@cherry.ease.lsoft.com>; Tue, 31 May 2005 18:29:51 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 73560668 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 May 2005 18:29:49 -0400
Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Tue, 31 May 2005 18:28:48 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 31 May 2005 18:28:49 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4VMSll6000486 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 31 May 2005 18:28:47 -0400 (EDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 18:28:46 -0400
Received: from [10.82.242.48] ([10.82.242.48]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 18:28:46 -0400
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2005 22:28:46.0808 (UTC) FILETIME=[1C3BED80:01C56630]
Message-ID: <429CE51E.8010909@cisco.com>
Date: Tue, 31 May 2005 18:28:46 -0400
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: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <000801c564cd$ffb0d760$ca04120a@china.huawei.com>
Precedence: list
Content-Transfer-Encoding: 7bit

sujay wrote:

>Hi Padma,
>
>Guess we *must* run the dead interval timer on a per neighbor basis,
>  
>
Hi Sujay,

IMHO, this is the norm rather than the exception.

>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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>     
>>>>
>>>>        
>>>>
>> 
>>
>>    
>>
>
>  
>