Re: Working Group Last Call for draft-ietf-ospf-hitless-restart-05.txt

[Acee Lindem <[e-mail]>]

alok wrote:
> so As MR deepak said
> ccing him
>
> no neighbour router suppout for this, (even one) nomore owrking of draft?

Almost - non-support from any neighbor that was fully adjacent prior to
restart will result in the restarting router aborting graceful restart when
it detects a discrepancy in the router's intra-area LSAs (i.e., type 1 or
2).

Publishing this draft as an RFC will go along ways towards promoting
universal support.

>
>
> ciao
> alok
>
>
> ----- Original Message -----
> From: Acee Lindem <[e-mail]>
> To: <[e-mail]>
> Sent: Friday, January 31, 2003 10:52 PM
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-hitless-restart-05.txt
>
>
>
>>Hi Alok,
>>
>>Let me attempt to address your points inline below.
>>
>>alok wrote:
>>
>>>Hi,
>>>
>>>there is something which I would appreciate if someone could clarify
>>>
>>>
>>>1. what is "restarting" and what is "after restarting" state?
>>
> essentially my
>
>>>concern being:
>>>
>>>page 2
>>>
>>>     (2)   The restarting router runs its OSPF routing calculations, as
>>>           specified in Section 16 of [1]. This is necessary to
>>>           return any OSPF virtual links to operation. However, the
>>>           restarting router does *not* install OSPF routes into the
>>>           system's forwarding table(s), instead relying on the
>>>           forwarding entries that it had installed prior to the
>>>           restart.
>>>
>>>what does point 2 mean?
>>
>>Conceptually, you have to have an OSPF route table that is independent
>>of the forwarding table(s). Virtual links will be marked UP as soon as
>
> there
>
>>is a transit area route to the virtual link's endpoint ABR. A restarting
>>router cannot update the forwarding table until it exits graceful restart.
>>
>>
>>>again mentioned on 2.3 point 3, it says after it has "exited restart
>>
> state"
>
>>>the routes will be put in the FT.
>>>
>>>what defines hitless restart time is the "grace period" which means "the
>>>router wont originate LSAs till LSRefreshtimer" :
>>>In order to avoid
>>>        the restarting router's LSAs from aging out, the grace period
>>>        should not exceed LSRefreshTime (1800 second)
>>
>>The grace interval expiring is only one of many reasons to exit graceful
>>restart.
>>
>>
>>>
>>>.....which anyways is the default operation if there is no topology
>>
> change.
>
>>>(i hope I am right here)
>>>
>>>doing it this way implies that if there is a topology change elsewhere
>>
> when
>
>>>the router is down, we would wait till the "old LSAs the router was
>>>orginating" become stale......to update the FT.
>>
>>Nope - if we receive a copy of our LSA that is inconsistent with the
>>pre-restart copy we will exit graceful restart immediately. See 2.2 (2).
>>
>>
>>>so why "wait" for that time at all before updating the FT
>>>
>>>would making the simple test be "grace period is over as soon as OSPF
>>>reestablishes adjacencies and time passed since the begininning of
>>
> restart
>
>>>is less than MinLSinterval"..hence start populating the FT with the new
>>>entries....
>>
>>An OSPF router will exit graceful restart prior to the grace interval if
>>it establishes all its prior adjacencies. See 2.2 (1). There are also
>>some implementation dependent wait condition relating to route
>
> redistribution
>
>>but those are beyond the scope of this document.
>>
>>
>>
>>>is my interpretation correct?
>>>
>>>-rgds
>>>Alok
>>>
>>>
>>>
>>>----- Original Message -----
>>>From: Acee Lindem <[e-mail]>
>>>To: <[e-mail]>
>>>Sent: Wednesday, January 29, 2003 7:28 PM
>>>Subject: Working Group Last Call for
>>
> draft-ietf-ospf-hitless-restart-05.txt
>
>>>
>>>
>>>>This is the start of a Working Group last call for
>>>>draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart.
>>>>All comments must be sent to the OSPF list by Friday,
>>>>February 8th, 2003.
>>>>
>>>>A URL for this Internet-Draft is:
>>>
>>>http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt
>>>
>>>>My previous list posting on this WG last call was lost or
>>>>filtering. My apologies if this is a duplicate.
>>>>
>>>>Thanks,
>>>>Acee & Rohit
>>>>--
>>>>Acee
>>>>
>>>
>>>
>>
>>--
>>Acee
>>
>
>


--
Acee