|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: alok (alok.dube_at_APARA.COM)
Date: Fri Jan 31 2003 - 11:29:52 CST
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 <acee
REDBACK.COM>
To: <OSPF
DISCUSS.MICROSOFT.COM>
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 <acee
REDBACK.COM>
> > To: <OSPF
DISCUSS.MICROSOFT.COM>
> > 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
>
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]