Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
Erblichs <erblichs@EARTHLINK.NET> Fri, 30 May 2003 07:19 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22438 for <ospf-archive@LISTS.IETF.ORG>; Fri, 30 May 2003 03:19:11 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009ED618@cherry.ease.lsoft.com>; Fri, 30 May 2003 3:19:09 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44132884 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 03:19:08 -0400
Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 03:19:08 -0400
Received: from user-38lc14i.dialup.mindspring.com ([209.86.4.146] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19LeAN-0003RY-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 00:19:07 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <LISTSERV%2003052814524118@PEACH.EASE.LSOFT.COM> <3ED509DA.C7720CAB@earthlink.net> <3ED516E3.35CF71BB@earthlink.net> <Pine.GSO.4.52.0305281550290.22012@irp-view7.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <3ED7062A.B5B24249@earthlink.net>
Date: Fri, 30 May 2003 00:20:10 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Erblichs <erblichs@EARTHLINK.NET>
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit
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
> > -------------------
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Abhay Roy
- Re: FW: Last Call: Detecting Inactive Neighbors o… Acee Lindem
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Abhay Roy
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Abhay Roy
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Abhay Roy
- Re: FW: Last Call: Detecting Inactive Neighbors o… Vivek Dubey
- Re: FW: Last Call: Detecting Inactive Neighbors o… Acee Lindem
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Alex Zinin
- Re: FW: Last Call: Detecting Inactive Neighbors o… Abhay Roy
- Re: FW: Last Call: Detecting Inactive Neighbors o… Erblichs
- Re: FW: Last Call: Detecting Inactive Neighbors o… Alex Zinin
- Re: FW: Last Call: Detecting Inactive Neighbors o… Vivek Dubey
- Detecting Inactive Neighbors over OSPF - repost Vivek Dubey
- Re: Detecting Inactive Neighbors over OSPF - repo… Abhay Roy
- Re: Detecting Inactive Neighbors over OSPF - repo… Acee Lindem
- Re: Detecting Inactive Neighbors over OSPF - repo… Vivek Dubey