Re: [OSPF] OSPF GR query

"Abhay D.S" <abhayds@acm.org> Wed, 06 December 2006 02:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grm5f-0008ED-Hf; Tue, 05 Dec 2006 21:00:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Grm5e-0008E8-A2 for ospf@ietf.org; Tue, 05 Dec 2006 21:00:54 -0500
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Grm5Y-0000U2-82 for ospf@ietf.org; Tue, 05 Dec 2006 21:00:54 -0500
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9T00MBRXJX47@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 06 Dec 2006 09:59:57 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J9T00LCRXJWC1@szxga02-in.huawei.com> for ospf@ietf.org; Wed, 06 Dec 2006 09:59:57 +0800 (CST)
Received: from [127.0.0.1] ([10.111.98.160]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J9T006WVXJNW4@szxml04-in.huawei.com> for ospf@ietf.org; Wed, 06 Dec 2006 09:59:56 +0800 (CST)
Date: Wed, 06 Dec 2006 09:59:47 +0800
From: "Abhay D.S" <abhayds@acm.org>
Subject: Re: [OSPF] OSPF GR query
In-reply-to: <4575B97C.90801@cisco.com>
To: Acee Lindem <acee@cisco.com>
Message-id: <45762413.9050203@acm.org>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_T0MzfP+3jQwyPoa/vGRCpQ)"
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
References: <988EE2C769AC284ABAE9328BFC10703F011AAD88@ZMY16EXM66.ds.mot.com> <45252069.10200@cisco.com> <b33c82d0610260041v216237d4w653d1042b9ec6bb@mail.gmail.com> <4575B97C.90801@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: ospf@ietf.org
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: abhayds@acm.org
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 acee,

Helper terminating graceful restart by flooding an inconsistent router 
or network LSA
can cause increased downtime.

It is exactly good IMHO to have explicit notification back to re-starter 
first.

The idea is with due respect to the critical interdependencies on OSPF 
routing on other
protocols, and how long we might allow and watch to flap, wrench and 
wrestle all the signalling, routing,
and other data protocols which depend on OSPF in the event of  a helper 
not co-operating.

This idea is above all the reason of whether to include this mechanism 
in grat(c)eful re-start.

It rather completes a old gr specification    ;-).

Thanks,
Abhay


Acee Lindem wrote:
> 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 mailing list
OSPF@ietf.org
https://www1.ietf.org/mailman/listinfo/ospf