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

Alex Zinin <zinin@PSG.COM> Fri, 30 May 2003 19:12 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 PAA23320 for <ospf-archive@LISTS.IETF.ORG>; Fri, 30 May 2003 15:12:58 -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 <16.009EE2F8@cherry.ease.lsoft.com>; Fri, 30 May 2003 15:12:57 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44184083 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 May 2003 15:12:55 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 30 May 2003 15:12:55 -0400
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19LpJ5-000Ohc-00; Fri, 30 May 2003 19:12:51 +0000
X-Mailer: The Bat! (v1.62i) Personal
X-Priority: 3 (Normal)
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> <Pine.GSO.4.52.0305300120100.23116@irp-view7.cisco.com> <3ED77888.2040301@redback.com> <3ED7934E.68E18ECD@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <119577854701.20030530121234@psg.com>
Date: Fri, 30 May 2003 12:12:34 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Alex Zinin <zinin@PSG.COM>
Subject: Re: FW: Last Call: Detecting Inactive Neighbors over OSPF Demand
Comments: To: Erblichs <erblichs@EARTHLINK.NET>
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <3ED7934E.68E18ECD@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Mitchell-

<hat=co-author>

Let me try to address some of your questions/concerns.

Friday, May 30, 2003, 12:20:10 AM, Erblichs wrote:
...
>         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.

Please note that the neighbor probing process and the LSA origination
process are not coupled. Regardless of how often I decide to probe my
neighbors, I will keep refreshing my LSAs as usual, the only
difference is in the sequence number in the LSA that will be found
in n'th and n+1'st probes.

Friday, May 30, 2003, 10:22:22 AM, Erblichs wrote:
> Abhay,

>         Actually, I would say, if the originator is
>         constantly "1 hr monotonomicly reachable",
>         then DNA LSAs can stay forever in the LS
>         tables.

Correct, and this is how it is supposed to work.

> Acee Lindem,

>         Interesting I always thought that
>         either active (sending) or a passive
>         (recieving) probing was a requirement
>         for an active DC OSPF speaker.

Not really. 1793 is based on the notion of "assumption of
reachability", which is quite important. With hello suppression
enabled, after a full adjacency has been established, we assume that
the neighbor is reachable unless we receive an explicit indication
proving this assumption wrong. 1793 mentions one possible
indication--failure of the dialer to reach the guy. The document in
question introduces another--failure of the reliable flooding
mechanism to deliver an LSA.

>         I classify DC nbrs that don't meet this
>         criteria for 1 hr, ....
>         (Sorry, Intellectural property and is
>         extraneous information) :-)

It is definitely possible to have implementation-specific mechanisms
that decide when to bring a DC neighbor down. Note though that your
approach may result in loss of connectivity when a multi-point dialer
(one with more than one next-hop-to-phone-num mappings) doesn't even
try to dial some remote locations due to the lack of application
traffic in that direction...

>         Lets work with your 2nd paragraph.

>         Lets assume that the nbr can not be probed for
>         over 1 hr and does not initiate a probe for
>         over 1 hr. And that all its interfaces are
>         DC based.

We should be clear whether you mean "a nbr is not probed for over 1hr
because of the ProbeInterval" or "a nbr does not reply to probes for
over 1hr". The latter is an indication of unreachability and should
be caught by ProbeRetxLimit. The former is completely normal.

>         Is it still a valid OSPF active speaker if
>         the only entries in its link state tables
>         are its own? Remember everything else is
>         flushed.

If all links are DC, then all received LSAs will be DNA. Provided that
the adjacencies are not brought down, I don't see how all other LSAs
could be assumed to be flushed.

However, regardless of the above point, it is absolutely normal for a
DC-connected router to not hear from its neighbor for more than one
hour, because there may be no application traffic going in its
direction and no topology changes that should be communicated to it.
So, yes, it is still a valid OSPF speaker. Keep the presumption of
reachability in mind.

>         Why would OSPF want to allow this level of
>         depricated implimentation? Doesn't it
>         just consume nbr slots forever?

See above about proving wrong assumption of reachability.

>         Why wouldn't you want to explicitly state
>         about stale LSAs? How many non OSPF
>         developers realize the consequences of
>         1 hr plus probes.

It is not clear to me what you are proposing to state
about stale LSAs.

Regards

Alex