[MLB-WIRELESS] Revisiting OSPF

[Dan Flett]

Hi all,

I've been having some discussions with the people on the Quagga-Users
mailing list about OSPF and routing in general.  The Quagga Mail Archive
doesn't list the thread properly so here are the interesting posts so
far:

My intial message:
http://lists.quagga.net/pipermail/quagga-users/2004-December/003350.html
James Haesu's response:
http://lists.quagga.net/pipermail/quagga-users/2004-December/003351.html
My response:
http://lists.quagga.net/pipermail/quagga-users/2004-December/003362.html
James Haesu's response:
http://lists.quagga.net/pipermail/quagga-users/2004-December/003365.html
David Young of the Champaign-Urbana Community Wireless Network's
response
http://lists.quagga.net/pipermail/quagga-users/2004-December/003375.html

The upshot of all this discussion is I've come to the realisation that
OSPF alone is not a suitable routing protocol for the entire Melbourne
Wireless network.

Why?

OSPF is an interior routing protocol.  An interior routing protocol is
one that is designed to be used within a single Autonomous System.  An
Autonomous System is a network or group of networks under a common
administration and with common routing policies.

The Melbourne Wireless Network has a common routing policy, but it can
not be said to be an Autonomous System, because it is not under a common
administration.  No one person or team of persons has administrative
privileges (i.e. root access) to all of the routers on the entire
Melbourne Wireless network.  To function properly - in a way that is
truly scalable, OSPF requires this.

OSPF requires that the network topology grow under the control of an
administrative body - which then assigns nodes to a backbone and,
optionally, to other 'areas'.  The Melbourne Wireless network grows
organically.  An administrative body, if there was one, has no real
control as to which nodes and areas will connect to which, and after the
network reaches a certain size, assigning nodes to OSPF areas after the
fact is messy and impractical - the administrative body would have to
make requests to node-owners to change their configuration - and rely on
the node-owners to do the changes properly and in a timely manner.  This
is not a good solution for network based on volunteers, most of whom are
not network engineers.

OSPF has strict requirements - the backbone area must be connected, and
all other areas must connect directly to the backbone.  However, as
we've seen over the past couple of years, the network will grow in ways
that don't necessarily meet OSPF requirements.

Through the use of LocFinder we have automated IP and OSPF area
allocation, which forms our Routing Policy.  But for OSPF to work, a
single administrative body would need to control all routers to
continuously redefine backbone routers, virtual-links and
shortcut-areas, as links between non-backbone-areas appear and
disappear.  Individual node-owners or Regional Groups are not allowed
the chance to define their own routing policy under such a system.  In a
community network, they should be allowed this chance - to be Autonomous
Systems unto themselves.

I believe we need to use an exterior or 'interautonomous system' routing
protocol as the main routing protocol, such as BGP.  If and when a true
backbone appears, under the control of a single administrative body, it
should use an interior routing protocol, such as OSPF alongside iBGP.
Region Group clusters can also form their own local backbones and run
OSPF or any other routing protocol they deem appropriate as a regional
Autonomous System.  The use of OSPF areas other than area 0 should
probably be discouraged as this adds a layer of administrative
complexity, and in any case, a regional AS probably would probably not
get big enough to warrant it.

The Melbourne Wireless network would then be seen as a network of many
Autonomous Systems, all speaking eBGP to each other at their gateways.
This is exactly how the Internet itself functions, and it has shown
itself to be highly scalable.  Regional Autonomous Systems, or even
individual nodes acting as an AS on their own, could view the rest of
the network as a "cloud" - ignorance is bliss - and let the exterior
routing protocol take care of things.  There would be no need for
routers in one AS to know about the link-states (and therefore the
network topology) in another AS.

I am quite interested in hearing people's opinions on this idea.  If we
can start to agree on things we can start to work out the details and
come up with a proposal for change.  At this point I'm happy to discuss
this on the main list.  If the discussion causes too much traffic that
non-participants don't want to read we can take it to another list or a
wiki page or whatever.

Cheers,

Dan

PS, there's a good intro to BGP here:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm
As always, Google is your friend.

To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message