Date: Tue, 21 May 2002 23:04:32 +1000
From: Dale Clapperton <dale-at-blackbird.net.au>
Subject: [IPv4] Debrief from meeting #2

Meeting began at ~1900 and closed shortly before 2100.  Attendance was me,
Luke, Tim, and Ben (I think it was Ben, I stink with names, sorry if it was
someone else).  No apologies.  I'm writing this in a brain-dump format, so
sorry if it rambles a little, but I want to do this and get it sent while it's
fresh in my brain.

We reviewed the ground covered by the previous meeting and then had a lengthy
discussion on the possable/probable topologies of the mesh, and how this would
affect the addressing/routing scheme.  We seemed to reach a consensus that
multiple interconnections between "access nodes" were likely because of
suitable geographical position, higher interest and dedication amoung the
access node operators, willingness to invest in equipment, etc; wheras "client"
would be less likely to multi-home, (ie daisy-chain themselves) especially in a
fully-meshed configuration because of the differing levels of skill, equipment,
time etc involved.

Was also noted that a perfect any-to-any meshing of nodes would either require
a large number of directional antennae at each site, which would be costly and
unlikely to happen, or every site (including sites which would otherwise be
"leaf nodes") would have to use omni-directional antenna, which we consider
contrary to best practice and which result in excessive RF pollution and
interferance.

We have noted that the mesh as it currently stands consists largely of small
"clusters" of nodes, often grouped around an involved dedicated individual,
often in a good geographical location and/or with superior equipment (hardware
AP's, very tall masts, etc).

We believe that an "organic" growth to join the current clusters is unlikely to
happen, for the reasons described previously for "client" nodes being unlikely
to daisy-chain.  It seems much more likely that interconnection/meshing will
happen between the access-nodes only and not (or rarely) at a "client" level.

Several people (including myself) are also currently working towards setting up
a node (possably in the CBD) which would allow for long-distance PTP "trunk"
links to tie the outlying clusters of nodes together.  Even if this does not
occur, for the reasons stated previously, access-nodes will likely interconnect
with other access-nodes, but client-nodes would be unlikely to interconnect
with eachother, and if they did, would/should be "promoted" to an access-node.

Therefore, we consider that the most likely topology for the mesh to evolve
into is one where access-nodes (I'll refer to them as AN's from here on)
interconnect with other AN's on a many-to-many basis, and possably also via one
or more dedicated "trunk" nodes ("TN") who serve to route traffic between AN's,
but who do not themselves provide access to end-users.

This topology would seem to lend itself best to a heirachial allocation of IP
space, where the top level of allocation is per AN.  At the moment an initial
allocation of /23 per AN seems to make sence.  The initial /23 allocations
would be interleaved within the initial /16 so as to allow adjacant "reserved"
space for future growth where it seems likely.  Ie an AN recieves 10.0.0.0/23
and 10.0.2.0/23 is "reserved", the next allocation being 10.0.4.0/23 (or later,
if an AN seems especially likely to grow).  If the AN grows beyond its initial
/23, it would apply for the "reserved" space and become 10.0.0.0/22.  If the
node did not grow, the reserved space would be later be allocated to another
AN.

Thus, the mesh "global" routing table should consist of a small/medium number
of routes, none less than /23.

We also consider there is the possability that end-user nodes within AN
clusters may mesh together.  (This would kind of break the definition of a
"leaf node").  This is currently happening (triangle-shaped clusters).
Provided that the meshing is within (and not between) AN clusters (the cluster
of nodes served by an AN) this does not present major issues for the routing
table as the additional complexity would be contained within the AN.

If end-users wish to multi-home between AP's, they should themselves
(preferably) become an AP and recieve their own /23 allocation, or act as a TN,
advertise the address space of each AN to which they connect to the other AN,
but must not advertise the allocation for their own use (ie their own personal
/28) to both AN's.  End-users wishing to multi-home between AP's but not
willing to carry traffic between them are selfish and can get bent.  (Will be
phrased more diplomatically in the final draft)

AN's would be free to sub-allocate their assigned space within set guidelines.
AN's requesting initial space would have to demonstrate they have sufficient
equipment, potential clients, good location etc to justify their own initial
/23 allocation.  For further allocations they would have to demonstrate their
existing allocations have been largely sub-allocated, in a non-wasteful
fashion, and they have a real need for more space (such as another AN coming
online "downstream" of them).

Leaf-node allocations would be at the discretion of the AN, but not greater
than /28 unless the leaf-node can demonstrate a need for > 16 IP addresses, and
in that case no greater than is required.  The use of NAT is preferable to
client allocations greater than /28.

Choice of routing protocol between AN's and TN's is down to OSPF vs BGP, the
merits of each to be the subject of further debate.  AN's will probably be free
to run any secure routing protocol they like (including no routing protocol)
within their own AN clusters, provided that only the routes for their top-level
allocations, plus any other TLA's whose routes they learn through AN-TN-AN or
AN-AN interconnection, are advertised outside that cluster.

Note that RIP is /not/ regarded as a secure routing protocol, especially on a
wireless network where traffic can be trivially intercepted, and forged routing
updates injected.

At this stage we propose to submit the working group's report in the form of a
report plus an RFC-style document which would (hopefully) be adopted as mesh
policy.

David: I've CC'ed you in on this so you can see where we are, and where we're
heading, and also so if you feel we're heading in the wrong direction you can
say so.  Once we have a finished document we will run it past you before we
table it.  If you think we've lost the plot, please say so.

To the working group participants:  Have a think about what to include in the
RFC.  Items should be phrased as "should", "should not", "must", "must not",
"may", "may not" etc.  Post your suggestions by 2100 on Friday night please,
I'll collate them into one document and email it to everyone ASAP, but no later
than Sunday night, and we will have another meeting on next Tuesday, same time,
same place, to discuss the RFC and report.

Dale