Re: Exit-Graceful Restart Condition

ashok holla <ashok.holla@GMAIL.COM> Wed, 25 May 2005 18:32 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 OAA06974 for <ospf-archive@LISTS.IETF.ORG>; Wed, 25 May 2005 14:32:00 -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 <15.0105B45D@cherry.ease.lsoft.com>; Wed, 25 May 2005 14:31:59 -0400
Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 72514611 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 May 2005 14:31:57 -0400
Received: from 64.233.184.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0l) with TCP; Wed, 25 May 2005 14:21:55 -0400
Received: by wproxy.gmail.com with SMTP id 58so578471wri for <OSPF@peach.ease.lsoft.com>; Wed, 25 May 2005 11:21:55 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s3zcIMjtScNIrXAGddCZrNTjRbUC/+8ucweMfXlRyqJ2+flVxA6jCgDkTEjqt0IHCLz6oAl3oxJgY0dX9A8woeVUNdkOncOcSR6Dn+f7VBrva7RjYTNe1w4/x5B7SWn1AhUwlpaEEOQsun+UjmfltPou1cYxErOTU4PhtMBy6VQ=
Received: by 10.54.45.2 with SMTP id s2mr1400226wrs; Wed, 25 May 2005 11:21:55 -0700 (PDT)
Received: by 10.54.46.73 with HTTP; Wed, 25 May 2005 11:21:55 -0700 (PDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <000001c56135$9cb892b0$ca04120a@china.huawei.com> <42949392.3060002@cisco.com> <4294A37E.2000000@cisco.com>
Message-ID: <4dbb3ecf05052511211a3138e6@mail.gmail.com>
Date: Wed, 25 May 2005 23:51:55 +0530
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: ashok holla <ashok.holla@GMAIL.COM>
Subject: Re: Exit-Graceful Restart Condition
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <4294A37E.2000000@cisco.com>
Precedence: list
Content-Transfer-Encoding: quoted-printable

Hi,
When myself and Sujay raised this issue, we thought about the
possibility which Pama and Acee suggested.
However, this will not work in all cases.

Consider:

TOPO------------------------ DUT---------------------------RTA
          Area0                                Area1
In this case, DUT will not get his pre-restart router of Area 1 as
there no other router in the area to give it to him.
Therefore, this solution fails. 
In this case, suppose DUT had run the spf, he would have seen that the
type-3 summary lsa he had advertised into area 0, is no longer
consistent with the topology and then could have exited GR. However,
this consistensy check can be done only after grace period terminates
as RTA MAY come up within that time.
So, for this case, there seems to be no solution.

However, it does seem to be worthwhile to start deadTimers for all
nbrs listed in the pre-restart router lsa when we get it for the first
time.  (even though we have not received hello pkts from them). When
any inactivity timer fires on the restarting router, he can quit GR.
This can be done to impro convergence incase, topology is unstable.

Is our understanding correct?

regards,
Ashok/Sujay


On 5/25/05, Acee Lindem <acee@cisco.com> wrote:
> 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.
> 
> 
> >
> > Padma.
> >
> >> For other routers in the network RTA is still reachable and traffic
> >> Will be eventually dropped.
> >>
> >> Kindly correct me,
> >>
> >> Regds,
> >> Ashok/Sujay
> >>
> >>
> >>
> >
> 


-- 
Best regards,
Ashok Chandrashekar Holla