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

[Erblichs <[e-mail]>]

Alex, Alex,

        Just 3 Inlines..

        And all of this is to suggest that a DC router in my opinion
        SHOULD send or recieve sucessful probes to/from each DC nbr
        within each monotomically hr.

        And that a successful probe will determine that a
        data-link is not closed and data will have a decent
        probably of being accepted. This does imply that
        the probe opens the connection, just that the
        connection is open at the time of the probe.

        Mitch or Mitchell
        ---------

Alex Zinin wrote:
>
> 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.

        If it is NOT, 1 hr REACHABLE, then DC DNA LSAs are
        flushed via rfc1793 2.3 - 2, in 1 hr time frame.

        This is specified specifly for DC router DNA LSAs,
        but will also occur for non-DNA LSAs, due to the
        fact of "reachability failure"., but will not
        allow updates to refresh non-DNA LSAs on
        the DC router, because..

        "..., OSPF Hellos and the refresh of OSPF routing
   information are suppressed on demand circuits, allowing the
   underlying data-link connections to be closed when not carrying
   application traffic."

        thus, Do you really think a OSPF router that only has
        its own LSAs can be a valid OSPF router?

        Justify to me that this router is doing any good after
        the link has been down for 1hr or more?

        ===============
=======================




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

        By stating that all links are DC, I am trying to imply that all
        the routers on those links are DC routers originating DNA LSAs.

        If data links at one router is down for 1 hr or more, then
        reachability is not met for that 1hr time frame and via rfc1793 the
        DNA LSAs are then flushed at the ONE router that had its links
        down!

        The other DC routers will only flush the one DC router that has
        not been reachable for that 1 hr timeframe.

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

        So, I would expect DNA LSAs to be flushed according to
        rfc1793 2.3 - 2!

        The presumption of reachability is that we can establish
        an open link before we send app data and that the router
        will exist on the other side. The adj exists forever..

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

        That stale LSAs are the result of a down link of 1
        hr or more after origination. See above for more.



> Regards
>
> Alex