|
Rick, Not sure there is a unique explanation, but I would take the statement with a grain of salt as I know of a couple of implementations that do things more intelligently and indeed avoid a Dijkstra recomputation (full SPF) when the change only affects a stub network in an area (in Section 16 of RFC 2328, the intra-area routing table computation is actually broken into two steps, with the second step being dedicated to adding stubs). I think the origin of this statement is that unlike IS-IS where because reachability information is encoded into separate TLVs there is a clean demarcation between running the (full) SPF (Dijkstra) using routers, pseudo-nodes and links connecting them, and what is called the partial route computation (PRC) that involves only the prefixes and not the topology, the situation is a bit murkier in OSPF. In particular, unless you do a detailed parsing of the RouterLSAs and NetworkLSAs to determine what has changed, the receipt of a changed one will often be used as a sufficient trigger to schedule a Dijkstra computation. Now this is again a necessary but not a sufficient condition, and some implementations will perform the additional parsing required to avoid a full SPF (Dijsktra) when it is not needed. hope this helps, roch
|
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
