Subject: Re: [OSPF] OSPF GR query

From: "Vivek Dubey" <[email-masked]>
Date: 12 Nov 2006 09:20:01 -0000

Hi Sujay,
I understand the reason for suggesting that a change in nbr fsm state at "restarting router" to  be taken as a topology change, and thereby exiting GR, hence the extension draft.

But on another note, taking into account default values  (rtr dead interval 40sec and grace period 120sec), if a helper fsm state at restarting router toggles from up-->down-->up within grace period, should we immediately declare that as topology change? Or let GR try be successful until GR period expires?

Thanks
Vivek

On Sun, 12 Nov 2006 sujay gupta wrote :
>Hi Amir,
>Adding  ;
>
>If the link between R1-R2 toggles making the adjacency going down and then
>come up.R1 should exit GR.
>R2  should exit  helper  mode send an inconsistent LSA to R1, R1 on
>examining this LSA should exit GR.
>Or; alternately R1 could detect a Nbr Down event and immediately exit GR.
>
>Regds,
>-Sujay
>( Ref
>http://tools.ietf.org/wg/ospf/draft-holla-ospf-update-graceful-restart-02.txtSection
>3.2.1(1))
>
>
>
>On 11/10/06, Abhay D.S <[email-masked]> wrote:
>>
>>  dear amir,
>>There is nothing called as Quitting GR.
>>
>>In the case below , the most desirable thing is to give a message or an
>>SNMP trap for qualifying to a quit scenario.
>>
>>There is a thin line between completion and quitting GR. Just imagine this
>>happens when the last router was about to be
>>full and  re-starter was  just about the originate  old router LSA ,
>>perfectly as the old one and then this event happened ?
>>
>>Would you quit GR or log a message.
>>
>>Another is what is your idea of quit GR  ?.
>>
>>Thanks,
>>
>>Abhay
>>
>>
>>
>>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(when R1 and R3 are in transition state) the
>>adjacency between R1 and  R2  goes down for some reson.
>>
>>  Considering above scenario, my doubts are:
>>
>>-  As the adjacency between R1 and R2 has gone down(which is a Topology
>>change) and R1 is still in GR mode, can R1 quit GR ? In general can a NBR
>>which was FULL and then later gone down can be treated as one of the
>>conditions for quiting GR ?
>>
>>
>>
>>
>>Regards
>>Aamir
>>
>>
>>
>>------------------------------
>>
>>_______________________________________________
>>OSPF mailing list
>>[email-masked]://www1.ietf.org/mailman/listinfo/ospf
>>
>>
>>_______________________________________________
>>OSPF mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ospf
>>
>>
>>
>>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "Vivek Dubey" <[email-masked]>
Date: 13 Nov 2006 05:46:31 -0000

Comments inline.

On Mon, 13 Nov 2006 sujay gupta wrote :
>Hi Vivek,
>I too had the same thoughts once, but concluded this way;
>
>a) Noting that GR successful completion is based on the forwarding
>plane being intact, the control plane on a possible restart.And in the given
>scenario a "link up/dwn" event has occurred which is probably indicative of
>the forwarding plane inconsistency. This event should be picked up as an
>exit-GR notification by the helper.
>
[vivek] NBR FSM getting down can be result of both control/forwarding plane issues. Tracking nbr fsm is not good enough indication to conclude where the issue is. More-ever in case of link up/down case, I would expect local event to "control plane" from some "port-mgmt" software (as an example). This would allow respective control plane software take relevant action.

>b) Even if the adjacency builds up and then goes down again for control
>plane
>reasons alone, a conservative and safer approach would bring down the GR.
>consider a worse case scenario of a misbehaving helper router or due to
>change
>in local policy on the helper( by some administrator) the helper has exit
>helping mode.
>
[vivek] I think the whole idea of GR is to take less conservative approach.

>c) Yet things may work even if the helper does not exit GR until grace
>period, however
>essentially as we follow a conservative approach in the routing area, it is
>*better* to quit!
>
>On second thoughts the whole idea as proposed in the original Moy GR that of
>detecting non
>helping routers through lsa consistency checks is not foolproof, some simple
>ways like sending
>a one-way hello , or a lls block signalling to the restarting router is more
>secure, fast and sure shot.
>
[vivek] Again as said above, original GR RFC even allows one to ignore topology change detected by LSAs (disabling strict lsa checking).

I think its more of a deployment choice. Taking conservative approach one should do as the extension-draft suggests. But if one thinks otherwise, he can very well let GR be successful, if possible.

>Btw which organization do you work for, Vivek?
[vivek] Motorola

>Thanks & Regds,
>Sujay
Thanks
Vivek

>
>
>
>On 12 Nov 2006 09:20:01 -0000, Vivek Dubey <[email-masked]>
>wrote:
>>
>>Hi Sujay,
>>I understand the reason for suggesting that a change in nbr fsm state at
>>"restarting router" to  be taken as a topology change, and thereby exiting
>>GR, hence the extension draft.
>>
>>But on another note, taking into account default values  (rtr dead
>>interval 40sec and grace period 120sec), if a helper fsm state at restarting
>>router toggles from up-->down-->up within grace period, should we
>>immediately declare that as topology change? Or let GR try be successful
>>until GR period expires?
>>
>>Thanks
>>Vivek
>>
>>
>>
>><http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
>>