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