OSPF Refresh and Flooding Reduction in Stable Topologies
RFC 4136

 ----- Begin forwarded message:
 
 From: Randy Bush <randy@psg.com>
 Subject: draft-pillay-esnault-ospf-flooding-05.txt
 Date: Thu, 12 Jun 2003 05:20:46 +0900
 To: iesg <iesg@ietf.org>
 
 ops-dir comment
 
 >    3.1 WG Submissions
 >       3.1.1 New Item
 > ******     o OSPF Refresh and Flooding Reduction in Stable Topologies 
 >              (Informational) 
 >              <draft-pillay-esnault-ospf-flooding-05.txt>
 >              Token: Fenner, Bill
 
 whew.. when I first read this, I thought this was for PS..
 
 ==> from an operational point of view, this seems like a totally useless 
 idea warranting editing or an IESG note, due to:
 
  * DC circuits spec is from 1995; they are practically dead/useless today, 
 who cares about the feature?  They're junk in the spec.
 
  * Now, this spec creates a dependency on DC circuit spec; this is useless 
 if DC circuit spec is not implemented in all OSPF routers
 
  * The bandwidth required for flooding a few LSA's every 30 minutes is 
 minimal.  Why bother with something like this which could lead to a lot of 
 issues?  OSPF is not BGP; it carries only minimal amount of information, 
 not the full Internet routing table, and flooding it once in a while is a 
 very good idea if it gains you even a piece or robustness.
 
 1. Abstract
 
 ==> abstract is numbered
 
 3. Changes in the existing implementation.
 
 ==> s/.//
 
 6. Security Considerations
 
    This memo does not create any new security issues for the OSPF
    protocol. Security considerations for the base OSPF protocol are
    covered in [1].
 
 ==> uhh, no.  what if you flood LSA's with noage bit, they stick around
 forever and are never purged?  I'd guess that changes the OSPF protocol
 assumptions quite a bit.  I didn't bother to check how well they were 
 documented in the OSPF DC circuits doc, but I wouldn't count on it.
 
 
 
 
 ----- End forwarded message: