Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand

[Abhay Roy <[e-mail]>]

Vivek,

Generally graceful restart techniques should finish well before
the probe retries (configurable) are finished. If it does not,
then yes, we will consider the neighbor dead. But it's not a big
problem, because the adjacency will come right back up.

I guess implementations could choose to factor in the grace period
to 'delay' probes.

Regards,
-Roy-

On 05/30/03+0530 at 8:48pm, Vivek Dubey writes:

> Roy,
> Suppose the time "Nbr probing" starts, the Ospf at the
> other end is undergoing "graceful restart"...(grace period
> 1800 sec).....
> while probing fails at this end.....
> should we consdier NBR dead or there is some "safeguard"
> in RFC 1793 - graceful restart - and Nbr probing draft, for such scenario.
>
>
>
> thanks,
> vivek
>
>
>
> -----Original Message-----
> From: Mailing List [mailto:[e-mail]]On Behalf Of Abhay
> Roy
> Sent: Friday, 30 May 2003 2:06 PM
> To: [e-mail]
> Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
> Demand
>
>
> Mitchell,
>
> The important point to note here is that: If the originator is
> 'reachable', DoNotAge LSA's can stay forever.
>
> Regards,
> -Roy-
>
> On 05/30/03-0700 at 12:20am, Erblichs writes:
>
> > Lets cover two stones with one throw..
> >
> >         Lets try part of this again..
> >
> >         In the 1793 RFC which deals with demand circuits,
> >         there is a 2.3 - 2) section that mentions MaxAge
> >         seconds, aka 3600 seconds or 1 hr.
> >
> > To ensure that these LSAs are eventually
> >       flushed from the routing domain, and that the size of the link
> >       state database doesn't grow without bound, routers are required to
> >       flush a DoNotAge LSA if BOTH of the following conditions are met:
> >
> > (2) The originator of the LSA has been unreachable (according to
> >     the routing calculations specified by Section 16 of [1]) for
> >             at least MaxAge seconds.
> >
> >         If probe exceeds 1 hr then LSAs are most likely
> >         dropped and LSAs need to be originated. Thus, tell
> >         me why you would want to allow LSAs to be forced
> >         to be re-originated in favor of a longer probe.
> >
> >         I also think you may get a dead nbr, but that is
> >         a different discussion point..
> >
> >         Mitchell Erblich
> >         Sr Software Engineer
> >         ---------------------
> >
> >
> > Mitchell,
> >
> > In case of 'always up' DC links, it does turn out to be periodic
> > probing. But in case of 'on demand' DC links, (if there is no data
> > traffic) it's of no use to bring up the link just to send probes.
> > So it makes sense to piggy back this event on the link coming up
> > event, and keep doing it periodically till the time line remains
> > up (due to data traffic).
> >
> > Regards,
> > -Roy-
> >
> >
> >
> > Abhay Roy wrote:
> > >
> > > Mitchell,
> > >
> > > Why it MUST not exceed 1hr? Today it's infinity, so in theory any
> > > interval (including absurdly high ones) should be allowed.
> > >
> > > Regards,
> > > -Roy-
> > >
> > > On 05/28/03-0700 at 1:06pm, Erblichs writes:
> > >
> > > > Sorry group,
> > > >
> > > >         I forgot..
> > > >
> > > >         E) If ..ProbeInterval is kept, its max value MUST not exceed
> > > >            1 hr..
> > > >
> > > >         I think this follows that if we haven't heard from our
> > > >         nbr in 1 hr "he" is considered dead.
> > > >
> > > >         Mitchell Erblich
> > > >         -------------------
> >
>
> ***************************************************************************
> This message is proprietary to Future Software Limited (FSL)
> and is intended solely for the use of the individual to whom it
> is addressed. It may contain  privileged or confidential information
> and should not be circulated or used for any purpose other than for
> what it is intended.
>
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient,
> you are notified that you are strictly prohibited from using,
> copying, altering, or disclosing the contents of this message.
> FSL accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including
> damage from virus.
> ***************************************************************************
>