OSPF Refresh and Flooding Reduction in Stable Topologies
draft-pillay-esnault-ospf-flooding-07

From the ops directorate (Pekka Savola):

 - abstract has been numbered
 - specific IPR notices are not allowed in the documents
 - non-updated boilerplates

Reviewed by Joel Halpern, Gen-ART

Given the history of this document, it is not enough to hold the document.

His review:

This draft is on the right track but has open issues, described in the review.

1) There is no description of what kind of information is "stable", how a
router would decide what is "stable", or even for a human being what
kinds of criteria ought to be applied to select information to be
flooded in accordance with this draft.  (I realize that there are
skilled practitioners who believe that there is no need for refreshes
of unchanged material.  But if the goal is to change the base behavior
of OSPF, rather more explanation for the existing behavior and why it
is reasonable to change it would be required.  The draft states that
it applies only to "stable" information.)

2) The document is inconsistent about whether this is a router behavior
or an interface behavior.  Most of the description indicates that an
originating router decides to flood some information with the "do not
age" bit set.  However, there are multiple references to
"flood-reduction interfaces.  Since a router may not send different
versions of the same LSA on different interfaces, and since the
description of forwarding of LSAs must be insensitive to the DNA bit
(and is correctly described as such), it is not clear what the
interface setting is intended to accomplish.

3) As a minor point, the description of "forced flooding" leaves the
reader to guess what is intended (probably, refresh even when there is
no change at an interval larger than the normal refresh interface.)
This should be explicitly described.