RE: [OSPF] OSPF GR query

"Khan Amir-G20247" <amirkhan@motorola.com> Thu, 05 October 2006 14:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg1-0007iR-QQ; Thu, 05 Oct 2006 10:58:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVUg0-0007c0-N2 for ospf@ietf.org; Thu, 05 Oct 2006 10:58:20 -0400
Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GVUdU-0003nW-9F for ospf@ietf.org; Thu, 05 Oct 2006 10:55:45 -0400
X-VirusChecked: Checked
X-Env-Sender: amirkhan@motorola.com
X-Msg-Ref: server-8.tower-125.messagelabs.com!1160060140!16662174!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 13393 invoked from network); 5 Oct 2006 14:55:40 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-125.messagelabs.com with SMTP; 5 Oct 2006 14:55:40 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id k95EtdHb001638 for <ospf@ietf.org>; Thu, 5 Oct 2006 07:55:39 -0700 (MST)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k95Etc0m014469 for <ospf@ietf.org>; Thu, 5 Oct 2006 09:55:39 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [OSPF] OSPF GR query
Date: Thu, 05 Oct 2006 22:55:23 +0800
Message-ID: <988EE2C769AC284ABAE9328BFC10703F011AAD88@ZMY16EXM66.ds.mot.com>
In-Reply-To: <452516EC.5070000@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OSPF] OSPF GR query
Thread-Index: AcboisdOAMkiNdx7S8+RjPh/zxYBIwAAkSiQ
From: Khan Amir-G20247 <amirkhan@motorola.com>
To: Acee Lindem <acee@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
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 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.

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