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

[Acee Lindem <[e-mail]>]

Another important point is that with the standard RFC 1793 behavior
an adjacency over a DC link will stay up indefinitely. So this
is an improvement no matter what the configured interval. Since
the probing is disabled by default it is somewhat contradictory
to put an upper limit on the probe interval (i.e., the default
probing interval is infinite ;^).

One could add a statement to the ospfIfDemandNbrProbeInterval
description saying. "An interval of less than 3600 minutes is
recommended to assure the stale DoNotAge LSAs are purged from the
link state database." However, I'm not sure that this adds all
that much value and would leave it to the discretion of the
authors.

Thanks,
Acee


Abhay Roy wrote:
> 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
>>>>        -------------------
>>>
>


--
Acee