Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
Abhay Roy <akr@CISCO.COM> Fri, 30 May 2003 08:35 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 EAA25136 for <ospf-archive@LISTS.IETF.ORG>; Fri, 30 May 2003 04:35:46 -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 <22.009ED7EB@cherry.ease.lsoft.com>; Fri, 30 May 2003 4:35:45 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44134151 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 04:35:44 -0400
Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 04:35:44 -0400
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4U8ZgFW023059 for <OSPF@PEACH.EASE.LSOFT.COM>; Fri, 30 May 2003 01:35:42 -0700 (PDT)
Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AHP56974; Fri, 30 May 2003 01:32:38 -0700 (PDT)
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> <3ED7062A.B5B24249@earthlink.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Message-ID: <Pine.GSO.4.52.0305300120100.23116@irp-view7.cisco.com>
Date: Fri, 30 May 2003 01:35:41 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Abhay Roy <akr@CISCO.COM>
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3ED7062A.B5B24249@earthlink.net>
Precedence: list
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 > > > ------------------- >
- 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