Re: [OSPF] OSPF GR query

Acee Lindem <acee@cisco.com> Tue, 05 December 2006 18:25 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GreyZ-0007Y6-Ef; Tue, 05 Dec 2006 13:25:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GreyY-0007Xr-7C for ospf@ietf.org; Tue, 05 Dec 2006 13:25:06 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GreyV-0003kt-Nl for ospf@ietf.org; Tue, 05 Dec 2006 13:25:06 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-4.cisco.com with ESMTP; 05 Dec 2006 10:25:02 -0800
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kB5IP29Z001148; Tue, 5 Dec 2006 13:25:02 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kB5IP2DM010782; Tue, 5 Dec 2006 13:25:02 -0500 (EST)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 13:25:02 -0500
Received: from [10.82.224.68] ([10.82.224.68]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Dec 2006 13:25:01 -0500
Message-ID: <4575B97C.90801@cisco.com>
Date: Tue, 05 Dec 2006 13:25:00 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: sujay gupta <sujay.ietf@gmail.com>
Subject: Re: [OSPF] OSPF GR query
References: <988EE2C769AC284ABAE9328BFC10703F011AAD88@ZMY16EXM66.ds.mot.com> <45252069.10200@cisco.com> <b33c82d0610260041v216237d4w653d1042b9ec6bb@mail.gmail.com>
In-Reply-To: <b33c82d0610260041v216237d4w653d1042b9ec6bb@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Dec 2006 18:25:01.0748 (UTC) FILETIME=[AD749F40:01C7189A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4088; t=1165343102; x=1166207102; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acee@cisco.com; z=From:=20Acee=20Lindem=20<acee@cisco.com> |Subject:=20Re=3A=20[OSPF]=20OSPF=20GR=20query |Sender:=20 |To:=20sujay=20gupta=20<sujay.ietf@gmail.com>; bh=LxKxjOF54/nCmBhGLBgGGgXNJJznS31UT+COswOU6po=; b=sgkaCdXsGOwPMO5dbkEJs8yH7F49dRiTYBrXtlXDsnqzqG2Y04g5A+43zqjU+NrqhbAQ22Rp L52YK96YfRtofEp2uZiTu2sUTeWzOZMQPvVBuJM/RTGzF/NJTxqtD6vm;
Authentication-Results: rtp-dkim-2; header.From=acee@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
Errors-To: ospf-bounces@ietf.org

Hi Sujay,
sujay gupta wrote:
> Hi Acee,
> A late mail on this thread.
>
> given the scenario if R3-R1 is a stub area
> and the incoming LSA is a type-5, even with strict LSA
> checking enabled will not exit Helper mode.
I'm not sure what the network picture looks like but a helper
router can always terminate graceful restart by flooding an
inconsistent router or network LSA to the restarting  router.

Thanks,
Acee

>
> It can be a nice idea to give some explicit notification
> by R2 to R1 about exiting helper mode.
>
> As rightly pointed by you the above conditions and more
> has been causing some confusion for some time.
> Our proposal ;
> http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txt 
>
> hopefully resolves this.
> Could we add this as an addendum/reference to RFC3623?, purely an
> add-on.
> Best Regards.
> Sujay
>
> On 10/5/06, Acee Lindem <acee@cisco.com> wrote:
>>
>> Khan Amir-G20247 wrote:
>> > Hi Ace
>> >
>> > But reaching to a FULL state is not one of the conditions for 
>> Helper to
>> > quit Helper mode, I guess a Helper who has reached
>> > to FULL state with its restarting router will wait for Grace LSAs 
>> to be
>> > flushed or GR timeout to happen for exiting Helper mode.
>> >
>> No - The presumption is when you reach FULL state you don't need to 
>> "quit"
>> helping - you have "finished" helping. Over the years, there have been a
>> few situations that could have been better documented - however, this
>> never
>> caused any confusion in the past.
>>
>> Thanks,
>> Acee
>>
>> > Regards
>> > Aamir
>> >
>> >
>> > -----Original Message-----
>> > From: Acee Lindem [mailto:acee@cisco.com]
>> > Sent: Thursday, October 05, 2006 8:00 PM
>> > To: Khan Amir-G20247
>> > Cc: ospf@ietf.org
>> > Subject: Re: [OSPF] OSPF GR query
>> >
>> > Hello Amir,
>> >
>> > Khan Amir-G20247 wrote:
>> >
>> >>
>> >>
>> >> Hi
>> >>
>> >> I have query related to OSPF Graceful Restart.
>> >>
>> >> Consider this scenario:
>> >>
>> >>
>> >>
>> >> - Three Routers R1, R2 and R3 connected via Broadcast networks.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> - Where R1 is a DR on both the segments, where as R2 and R3 are in
>> >> DR-other
>> >> - Now R1 wants to perform GR, R2 and R3 agrees to be its Helpers.
>> >> - Now after restart R1 will try to form adjacency with both R2 and 
>> R3.
>> >>
>> >
>> >
>> >> - Lets say R1 and R2 had become FULL, while R1 and R3 had reached
>> >> Exstart state.   Now at this time R2 receives an LSA (any type 1-5 
>> and
>> >> 7, from some other router existing in the same area, not pictured
>> >> here) which he needs to flood to R1.
>> >> - This will force R2 to quit Helper Status, while R1 and R3 are still
>> >> in process of forming adjacency.
>> >>
>> >>
>> > Since he has reached FULL state, he is no longer a helper router.
>> >
>> >> Considering above scenario, my doubts are:
>> >>
>> >> - How will R1 come to know that its Helper R2 has quit?
>> >>
>> >>
>> > Since he has reached FULL state, he is no longer a helper router.
>> >
>> >> - Will the adjacency between R1 and R2 needs to go down, as R2 quits
>> >> helper mode?
>> >>
>> >>
>> > No
>> >
>> >> - Will this effect the adjacency formation of R1 and R3?
>> >>
>> >>
>> > No. R3 MAY exit helper status and re-originate a new router LSA if he
>> > receives the new LSA before reaching FULL state with R1 AND he is has
>> > strict-LSA-checking configured.
>> >
>> > Hope this helps,
>> > Acee
>> >
>> >>
>> >>
>> >> Regards
>> >> Aamir
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 
>> ----------------------------------------------------------------------
>> >> --
>> >>
>> >> _______________________________________________
>> >> OSPF mailing list
>> >> OSPF@ietf.org
>> >> https://www1.ietf.org/mailman/listinfo/ospf
>> >>
>> >>
>> >
>> >
>>
>> _______________________________________________
>> OSPF mailing list
>> OSPF@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ospf
>>
>

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf