OSPF Refresh and Flooding Reduction in Stable Topologies
Note: This ballot was opened for revision 07 and is now closed.
( Bill Fenner ) Yes
( Harald Alvestrand ) (was Discuss) No Objection
Comment (2004-09-16 for -07)
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.
( Steven Bellovin ) No Objection
( Ted Hardie ) No Objection
( Scott Hollenbeck ) No Objection
( David Kessens ) (was Discuss) No Objection
Comment (2004-06-23 for -07)
From the ops directorate (Pekka Savola): - abstract has been numbered - specific IPR notices are not allowed in the documents - non-updated boilerplates