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

[alok <[e-mail]>]

so As MR deepak said
ccing him

no neighbour router suppout for this, (even one) nomore owrking of draft?


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
>