[MLB-WIRELESS] So how does this routing bit work?

[Ben Anderson]

> On Friday 29 March 2002  9:31 am, Ben Anderson wrote:
> > If we, for example, threw out the network layer (which we could think
about
> > say on an unrouted ethernet cloud), we could still make everything work
by
> > getting packets around just by MAC address...  My point is we can keep
the
> > IP layer, but use layer 2 to keep the majority of the smarts in routing
> > packets around the wireless mesh (I still think looking at layer 3 and 4
> > state information will be useful in layer 2's routing strategy, but it
> > shouldn't need to modify data, just listen to it)
>
> not sure what your position is on this, but don't even think of layer 2
> 'routing'. that's definitely the scalable role of this IP thingie.

I have no idea what you're trying to say here...  One of us is an idiot,
going by that...
Can you rephrase your last statement?


> > You find a solution that solves the problems I want to solve, and I'll
use
> > it.  I don't believe it exists, which is why I'm looking at engineering
a
> > solution.  American and Europe, for all they've contributed, aren't the
> > only source of innovation.
>
> Actually, a significant part of the innovations up north come from
wandering
> aussies. ;)

I know, I know...  I just get irritated by people expecting other people to
innovate so they can leech their ideas, and then at the same time discourage
other people from innovating...  Phools.


> seattlewireless, consume, free2air and other groups are testing various
> tunnelling (GRE, L2TP,PPTP, IPsec) and routing protocols (OSPF, AODV) and
> dynamic systems (mobilemesh, mobile IP, RSIP, etc) their application over
> public access wireless infrastructures.

I know, I've looked at all the projects I could find that were already
going...  I'm dissapointed in all of them so far.


> I know this sounds obvious, but a large part of the problem is defining
the
> requirements.

Yep.  My requirements are fairly well defined in "ubiquitous public network"
Data, anywhere, anytime, for everybody.

> a start?
>
> - coordinated, distributed IP netowrk allocation and management
> - highly distributed route management & ownership
> - secure authenticated route distribution

There's many ways to solve the problem.  Defining the problem domain like
you do lends to utilising and layering on top of existing solutions that
don't solve the problem, rather than engineering something to fundamentally
solve the problems that exist.
All I'm trying to point out is that the definition should be kept loose to
allow as much innovation to solve the fundamental problems.


> > Short term, out of the box makes sense.  Long term, a better out of the
box
> > solution makes sense.  It's this better solution that I'm trying to get
> > built.
>
> Agreed. I think that OOTB is best, and the medium term solution lies in
> agreement on how existing packages can be implemented and configured to
> achieve our goals.

Sure, but that's not where my interest lies.  I want ubiquitousness, and
existing packages don't, and are unlikely to, solve the problems in the way
I desire.

> IMO, this is mostly a human organisational problem, not a technical one.

Human organisational problems don't scale well...   Having a centrally
controlled 'wireless' organistion somewhat detracts from the 'freeness'
that's possible with the peer to peer architecture...
If we went from a dozen nodes to ten thousand overnight, I seriously doubt
that organisational demand could be satisfied on a volunteer basis...

Ben.