Re: Exit-Graceful Restart Condition

Padma Pillay-Esnault <ppe@CISCO.COM> Fri, 27 May 2005 15:10 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 LAA19565 for <ospf-archive@LISTS.IETF.ORG>; Fri, 27 May 2005 11:10:12 -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 <2.0105FF39@cherry.ease.lsoft.com>; Fri, 27 May 2005 11:10:11 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72772138 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 27 May 2005 11:10:09 -0400
Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Fri, 27 May 2005 11:10:09 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 27 May 2005 08:10:09 -0700
X-IronPort-AV: i="3.93,144,1115017200"; d="scan'208"; a="639098977:sNHT30802868"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4RF9gm8008928 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 27 May 2005 08:10:02 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 08:10:00 -0700
Received: from [192.168.0.2] ([10.21.90.253]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 08:10:00 -0700
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com> <42949392.3060002@cisco.com> <4294A37E.2000000@cisco.com> <03e201c56152$44214210$a328fb80@Kishorepc> <4294BBCC.5010607@cisco.com> <03fc01c5615b$2bcde840$a328fb80@Kishorepc>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 May 2005 15:10:00.0223 (UTC) FILETIME=[26B6DAF0:01C562CE]
Message-ID: <42973845.9070404@cisco.com>
Date: Fri, 27 May 2005 08:09:57 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Padma Pillay-Esnault <ppe@CISCO.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <03fc01c5615b$2bcde840$a328fb80@Kishorepc>
Precedence: list
Content-Transfer-Encoding: 7bit

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