RSPF hangups

["k1io@fn42jk 28-Jan-1991 1707" <goldstein@carafe.enet.dec.com>]

With regard to Gareth's problems running RSPF, Anders beat me to the
punch to say that the first thing to do is to increase the time in
between full updates.  What seems like an eternity on a wireline LAN
is a blink to a 1200 bps Aloha radio channel!

The second thing -- is this implemented, Anders? -- is to check up
on how node groups are being handled.  The idea is that a given end
system needn't be running RSPF nor even mentioned in a routing update IF
the IP address is within a node group default.  For example, my address
is 44.56.4.44.  I would like for WA1PHY to be the node that people use
to reach me.  So if WA1PHY reports that it has connectivity to
44.56.4.0/25, then any address in the range 44.56.4.0 to 44.56.4.127 is
assumed to be there.  Anybody reporting a greater-number-of-bits match
will automatically override, so if 44.56.4.43, say, is NOT there, and IS
somewhere else, then that somewhere_else (reporting 44.56.4.43/32) will
get traffic for it, even if the cost metric is higher.

This way, RSPF reports which routers cover which areas, and which ones
carry out-of-area addresses (visitors).  Node groups are a hack and not
what IP is nominally about, but they can save on traffic, making them a
useful hack. (After all, that's how most manual routing tables are
built.)
   fred k1io