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

[Erblichs <[e-mail]>]

Abhay,

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

Acee Lindem,

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

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

        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.

        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.

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

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

        Mitchell Erblich
        Sr Software Engineer
        --------------------



Acee Lindem wrote:
>
> 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