[Goat] routing

[William Waites]

On Sun, Apr 25, 2004 at 10:10:08PM -0400, Benoit Grégoire wrote:
> >
> >       \|/  ...  \|/             \|/  ...  \|/
> >        |         |               |         |
> >      +---+     +---+   +---+   +---+     +---+
> >      | A |     | B |---| C |---| D |     | E |
> >      +---+     +---+   +---+   +---+     +---+
> 
> 1- Run the same routing protocol on nodes B, C and D as the rest of the mesh.  
> Note that that does not imply that it's the only routing protocol that is run 
> on those three nodes, only that the protocols do not talk to each other.  
> "Node" C  only hears two other nodes (B and D), but with very high speed and 
> reliability.
>
> 2- We don't want to bother with the problem, and simply add a VPN (or PPPoE, 
> or  whatever) between  B and  D, making  the two  of  them broadcast
> reachable. 

What happens if C is plugged into a hub with some servers that
don't participate in the protocol? 1 doesn't work because there's
no way to tell the other nodes about those servers "care of" this
gateway, 2 doesn't work because C doesn't exist.

> 3- We make the wired and wireless protocols talk to each other.

	[...]

> Indeed, I don't see much benefit in cross connecting the protocols.

We must if we want servers like people's home linux boxes
to be reachable from other sites on the network. This is not 
possible with SrcRR alone.

> Say we are in case 1 or 2 above and the routing protocol for the wireless part 
> is RoofNet (and for node C as well in case 1).  Roofnet's metric can be 
> summarised as the mant time for sucessfully transmiting a packet.   

	[...]

> Well, the case I was discussing is if someone were to connect
> an existing LAN  to the MESH.  The wireless protocol would be
> wastefull inside the LAN,

Of course. But ScRR deals with reachability within the
MESH (or sub-mesh) not reachability to outside destinations
like the LAN.

SrcRR is a very good layer 2 protocol. But the other MESH
nodes have to know about the subnet that lives on the LAN.
ScRR doesn't solve this. The RoofNet guys solve it with NAT,
which just ignores the problem (because they're concerned 
with giving people Internet access)

> Now for small lan, it will be much simpler to simply run the wireless
> routing  protocol everywhere and be done with it.

What address do you give the computers on the LAN?

> > > - -No centralised network management.
> >
> > this is not required with ospf or bgp either -- all
> > that is required is for you to get your neighbours
> > to talk to you.
> 
> In the trivial case, I'll grant you that.

Are you saying that interdomain routing is centralized?
The degree of centralization lies with how "domain" is
defined. Each autonomous system is just that: autonomous.
Without changing BGP at all, there are 65k autonomous
system numbers, with a population of 3,000,000 that's
one for every 45 people with no operational centralization.

> Ok, perhaps I worded that badly.  Radio links can have 
> a whole range of intermitent falures and packet loss. 
> It was my understanding that OSPF and similar routing
> protocols can take up to several minutes to detect link
> state change.

True, although tuneable somewhat with the timers. The
tradeoff is rigidity (response time to failures) vs.
scalability. BGP scales very well but requires very
reliable links. OSPF scales badly and requires
mostly reliable links. ScRR scales badly (it uses
Dijkstra like OSPF so has the same scaling properties)
but can deal with inconsistently lossy links.

Covering the island with SrcRR won't work. Connecting
a bunch of SrcRR networks with OSPF and BGP might work.
OSPF can then run over SrcRR so that the routers at the
edge of ScRR clouds know about next hop reachability.
BGP can isolate OSPF clouds to the degree of autonomy
required for sociological as well as scalability reasons.

This works because SrcRR makes the wireless meshes
look reliable to OSPF. I'd like to test this out,
perhaps at the next hack night.

> One of the premise for my analysis of each protocol
> is that manual configuration at each nodes and
> contacting each neighbour nodes to get on the  network
> are not reasonnable requirements for the sociological
> and economic model of the mesh to work.

The one crucial thing that has to be solved and that
SrcRR provides no immediate answer to is how to make
subnets that are not part of the wireless stuff
addressable directly over the wireless stuff. RoofNet
tries to solve it with NAT, which is not an option.

Once it is solved, we can figure out how to minimize
the configuration so that people that aren't interested
in knowing much about the nuts and bolts of the routing
can participate.

-w
-- 
The sum of the Universe is zero.

_______________________________________________
Goat mailing list
Goat at isf.waglo.com
http://isf.waglo.com/mailman/listinfo/goat_isf.waglo.com