Diff: OSPFRevisited

--- Version 2 

+++ Version 3 

@@ -6,12 +6,11 @@ 

 

 [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 a network based on volunteers, most of whom are not network engineers. 

+control as to which nodes and areas will connect to which.  After the network reaches a certain size re-assigning nodes to new 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 a network supported by 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. 

+[OSPF] has strict requirements - the backbone area must contiguous, 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. 

+Through the use of LocFinder we have automated IP and OSPF area allocation, which forms our Routing Policy.  But for OSPF to work properly, 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 can not be allowed the chance to define their own routing policy under such a regime.  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.