Re: [OSPF] OSPF GR query

["Vivek Dubey" <[e-mail]>]

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 <[e-mail]>
>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
>>
>>
>>
>>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 <[e-mail]> 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
>> >>[e-mail]://www1.ietf.org/mailman/listinfo/ospf
>> >>
>> >>
>> >>_______________________________________________
>> >>OSPF mailing list
>> >>[e-mail]
>> >>https://www1.ietf.org/mailman/listinfo/ospf
>> >>
>> >>
>> >>
>> >>
>> >_______________________________________________
>> >OSPF mailing list
>> >[e-mail]
>> >https://www1.ietf.org/mailman/listinfo/ospf
>>
>>
>><http://adworks.rediff.com/cgi-bin/AdWorks/sigclick.cgi/www.rediff.com/signature-home.htm/1507191490@Middle5?PARTNER=3>
>>
>>_______________________________________________
>>OSPF mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/ospf
>>
>>
>>

_______________________________________________
OSPF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf