Subject: Detecting Inactive Neighbors over OSPF - repost

From: Vivek Dubey <[email-masked]>
Date: Thu, 5 Jun 2003 16:45:20 +0530

if lost in flood of mails ......

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Vivek
Dubey
Sent: Saturday, 31 May 2003 12:43 PM
To: [email-masked]
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand

Roy,
Adjacency will be restored up again but
won't the purpose of "graceful restart" somewhat
defeated then (NBR is needlessly considered dead -
though it is trying graceful restart).

Won't it be better, if it is explicitly mentioned:
1)Generally graceful restart techniques should finish well before
  the probe retries (configurable) are finished(as you said in reply).
OR
2)If the router has received grace LSA from other end
  point.... delay "Nbr probing" till "graceful restart"
  process completes.

thanks,
vivek

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Abhay
Roy
Sent: Saturday, 31 May 2003 1:17 AM
To: [email-masked]
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF
Demand

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:[email-masked]]On Behalf Of Abhay
> Roy
> Sent: Friday, 30 May 2003 2:06 PM
> To: [email-masked]
> 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.
>
***************************************************************************

***************************************************************************
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.
***************************************************************************

***************************************************************************
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.
***************************************************************************

---

From: Abhay Roy <[email-masked]>
Date: Thu, 5 Jun 2003 13:59:47 -0700

Vivek,

I discussed this with my co-authors.. And we think that this
should work just fine if the router supports (and is doing)
graceful restart..

The Grace LSA tells us to continue announcing the adjacency even
if it goes down. The restarting router will _reset_ its
adjacencies anyways, and we are going to see this. If the probe
goes out and fails before, the grace period should cover it.

Regards,
-Roy-

---

From: Acee Lindem <[email-masked]>
Date: Thu, 5 Jun 2003 17:14:46 -0400

Roy,

I was meaning to make the same point but got tied up today.

Vivek,

Look at section 3.0 in draft-ietf-ospf-hitless-restart-07.txt. Note
that the neighbor going to DOWN state doesn't necessary cause
the helper to exit graceful restart.

Thanks,
Acee

--
Acee

---

From: Vivek Dubey <[email-masked]>
Date: Sat, 7 Jun 2003 14:13:05 +0530

Hi Acee, Roy:

Section 3.0 in draft-ietf-ospf-hitless-restart-07.txt :
======================================================
"This means that Y's LSAs continue to list an adjacency
to X over network segment S,regardless of the adjacency's
current synchronization state. "

Section 2.1 draft-ietf-ospf-dc-06.txt
======================================
If no acknowledgement (explicit or implicit) is received for a
predefined period of time, the probing router should treat this as
evidence of the neighbor's unreachability (proving wrong the
assumption of reachability used in [RFC1793]) and should bring the
adjacency down.

Agreeing that "graceful restart" at helper
should "override" the Nbr dead, detected by
"Nbr probing" at helper.

But my concern was, this is not very clear from
draft itself.....implementors might miss it....
so it would be better if it is explicitly mentioned
somewhere.....

But leaving it to discretion of authors.

thanks,
vivek

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Acee
Lindem
Sent: Friday, 6 June 2003 2:45 AM
To: [email-masked]
Subject: Re: Detecting Inactive Neighbors over OSPF - repost

Roy,

Vivek,

Thanks,
Acee

--
Acee