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
- [OSPF] OSPF GR query Khan Amir-G20247
- RE: [OSPF] OSPF GR query Don Goodspeed
- Re: [OSPF] OSPF GR query Acee Lindem
- [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Acee Lindem
- RE: [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Acee Lindem
- Re: [OSPF] OSPF GR query sujay gupta
- [OSPF] OSPF GR query Khan Amir-G20247
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query sujay gupta
- Re: [OSPF] OSPF GR query Vivek Dubey
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query Vivek Dubey
- Re: [OSPF] OSPF GR query Acee Lindem
- Re: [OSPF] OSPF GR query Abhay D.S
- Re: [OSPF] OSPF GR query sujay gupta
- Re: [OSPF] OSPF GR query Acee Lindem