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

[Alex Zinin <[e-mail]>]

Mitchell-

Let me try one more time.

Starting with inlines, a bit out of order though:

[...]
>         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!

This seems to be the source of the confusion.

The fact that the data link to a guy has not gone up for 1h or more
does NOT mean that the reachability condition has not been met.

The 1hr originator reachability condition is checked through SPF, and
1793 is very explicit about it. This means that as long as you have
NOT received an evidence of unreachability of your neighbor, the
adjacency will stay up, and you (as well as other routers) will
consider the guy reachable even if the data link has never gone up.

[...]

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

Refreshes never come on the DC links, and don't have to.
If you have non-DNA LSAs then you have non-DC links and
the refreshes will come on them, not on the DC links.

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

Yes, see my previous message

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

ditto


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

Nope. I think you are confused with what "Reachability" means.
See my first comment above.

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

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

This is not true, as the originator is still reachable because
the adjacency is still up.

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

I don't think we should put this in the spec. I also believe this will
cause problems with multi-point dialers (see last paragraph in Section
2 of the document.)

On the other hand, if you believe this is useful, you can definitely
add this to your implementation and still successfully interoperate.

Alex