c> This is the one of the main points, should a node broadcast
c> a nodegroup that is basically the network it sits on? The
c> "default answer" is no, it shouldn't.
c> A nodegroup is a statement saying that the sender of the
c> nodegroup is the best or one of the best places to attempt
c> to reach *everyone* in that nodegroup. It is used mainly
c> for home ethernet LANs and also for a main node in a radio
c> network, such as a packet/internet gateway.
c> Now remember that a route that is in a node group is treated
c> differently to a route that is outside it. A route that is
c> in a node group is a local route, it has a low horizon so it
c> should only be seen by "the locals" ideally everyone that is
c> included in that nodegroup. Everything else is "portable"
c> and should have a horizon which is the same as the nodegroup
c> So what should happen is that the main node or nodes of a
c> network, ie the stations that have the best chance of
c> reaching most of the nodegroup, should have this entry;
c> everyone else should not.
c> This just leads to an interesting problem; the non-main
c> nodes will treat everything as outside the nodegroup (as
c> they have none) and so give them long "portable" horizons,
c> this seems incorrect behavour to me.
I proposed a partial solution with my "Rhode Island Standard" back in 1991:
4. RSPF for end-users should be instructed to use an interface
cost of 8 and horizon of 1. Switches should use a cost of 7
so that they are slightly preferred; this is not a peer to
peer network. Hubs among switches should use a cost of 6.
Switches and hubs should use a horizon that works for their
network, probably not more than 12. Here is the usual setup
for an end-user:
rspf interface ax0 8 1
(Multi-port systems may, in some cases, use a different cost on
some interfaces. To do this, set cost 8 for the preferred
interface or interfaces, with a cost of 9 on the less preferred
ones. This is unexplored territory.)
What I was really trying to cope with in the paragraph above was the unique
problem of dynamically figuring out which RSPF routers were willing to relay
for others. Just because a bunch of stations are on the same frequency
obviously has never implied that they could all hear each other, since radio
works very differently from Ethernet. One of the central purposes of RSPF was
to establish ways of handling this common situation automatically. This
necessitates publishing routes via RSPF which may not be of any immediately
apparent value until some new station comes up and can reach some stations but
not others. This is also why I have never agreed with Fred's view that end
users should not themselves run RSPF, since my view is that someone who offers
to route for others even if there are no takers is not purely an end user.
Because radio is so fundamentally unlike Ethernet, I view the Linux kernel
practice of establishing implicit routes based on "ifconfig" commands to be a
Very Bad Thing. Linux needs to be able to recognize that implicit routing,
while direct, may not work for a particular host which requires a relay. In
other words, we don't really want the shortest path; rather, we want the
shortest useful path.
The proposed rule formulated above basically says this: first, try direct;
second, try going through the preferred router; third, try going through any
RSPF router who claims to know a route.
-- Mike, N1BEE