[MLB-WIRELESS] FW: Proposal for a new Melbourne Wireless routing policy

Tom Fifield gummay at gummAY.net
Tue Jan 25 14:28:15 EST 2005


Dan, you're an ideas man.

As a web monkey, I can forsee no problems with implementing.

As one of those Cisco 'piece of paper' holders, the routing changes 
makes sense.

Changes proposed for the website can be made on the dev site to see how 
they work before committing to anything on the real site.

Regards,

Tom

Dan Flett wrote:
> Hi all,
> 
> I've not received any commentary at all on this proposal yet.  Perhaps my
> original posting was not all that well-timed.
> 
> I would like to get some sort of feedback on this - even if it's just "good"
> or "no good" - be it publicly on the list (preferable) or privately.
> 
> I am hoping to put this proposal, modified with any feedback, to the
> committee so we can modify LocFinder and begin a trial phase.
> 
> Cheers,
> 
> Dan
> 
> -----Original Message-----
> From: Dan Flett [mailto:conhoolio at hotmail.com] 
> Sent: Thursday, 20 January 2005 6:04 PM
> To: melbwireless at wireless.org.au
> Subject: Proposal for a new Melbourne Wireless routing policy
> 
> In the midst of all this "why are we here?" discussion, I hope people have
> time to digest and respond to some nitty-gritty future-direction stuff. ;)
> 
> Here's my proposal for a new, BGP-based routing policy for our network.
> 
> This would replace the current OSPF-Area-based policy.
> 
> By coincidence, or convergent-thinking, this proposal resembles a one put
> forward by Sydney Wireless here:
> http://www.sydneywireless.org/index.php?pagename=BackBone&action=PageInfo
> 
> I would like this proposal to be reviewed and critiqued by any interested
> persons.
> 
> Glossary:
> 
> AS: Autonomous System - a network of nodes under common direct
> administration, using a single internal routing protocol.
> 
> ASN: Autonomous System Number - as used in BGP
> 
> BGP: Border Gateway Protocol - an external routing protocol
> 
> Cluster: A geographically close grouping of nodes.
> 
> IETF: The Internet Engineering Task Force
> 
> Link: A connection between two nodes
> 
> Node: A point of connection to a network
> 
> OSPF: Open Shortest Path First - an internal routing protocol
> 
> 
> I propose the following:
> 
> * Keep the current geographic area-based IP allocation scheme as
> administered by LocFinder. (See Note 1)
> 
> * Allow any "Operational" or "Testing" nodes to request a BGP ASN from
> LocFinder.  LocFinder will keep track of which ASNs have been allocated in
> an ASN allocation database, just as it currently does with IP addresses.
> ASNs will be allocated from the IETF ASN Private Space - being #64512 -
> #65535.  This allows for 1023 BGP "areas". (See Note 2)
> 
> * To allow for the possible depletion of private ASN space, nodes within a
> closely linked cluster can choose to share a BGP ASN amongst themselves and
> use an internal routing protocol such as OSPF.  From a LocFinder point of
> view, any node should be allowed to choose the ASN of any of it's link
> partners instead of requesting a new, unique ASN for itself. (See Note 3)
> 
> * Any node with a single link (a leaf or client node) to one other node does
> not need to run any routing protocol at all.  A default route, installed by
> the "other" node via DHCP will be sufficient.
> 
> * A node with two or more links to nodes within a singe AS cluster does not
> need to run BGP, but does need to run the internal routing protocol of that
> cluster (e.g. OSPF).
> 
> * A node which makes links to nodes outside its home AS cluster needs to run
> BGP.  The node configuration will need to know the following:
>  ** The nodes' own ASN
>  ** The ASNs of it's link partners
>  ** The IP addresses of other BGP speakers in the nodes' home AS - this is
> so that the node can use iBGP to coordinate eBGP routing information to
> other border gateways.
>  ** Internal routing protocol configuration and redistribution of routes
> between BGP and the Internal Routing Protocol (e.g. OSPF)
>  (See Note 4)
> 
> Notes:
> 
> 1. I no longer believe that the region group supernetting used in the
> current IP allocation scheme will help with routing by allowing the
> aggregation of routes.  The nature of wireless networking means that it is
> impossible to predict where clusters will form and which areas will link to
> which.  I can see no easy way of allocating IP addresses to enable route
> aggregation.  However I believe that we can just accept this as a fact of
> life.  The current IP allocation system isn't broken and doesn't need to be
> changed.  If in the future the address space of any area becomes depleted,
> the unused space of other areas could be used.
> 
> 2. I believe it will be a long time before we have more than 1023 routing
> nodes on the network.  So until that happens, do we need to run internal
> routing protocols at all?  Will a BGP-only network work, where each routing
> node has a unique ASN?  By the time we reach 1023 routing nodes, the BGP
> protocol will likely have been updated to allow more ASNs overall.
> 
> 3. Clusters that use OSPF should enable simple authentication on their
> interfaces - and the authentication password should be that cluster's BGP
> ASN.  This will prevent OSPF in neighboring clusters from communicating
> directly, and will help prevent OSPF from being destabilized by
> misconfigured or default-configured routers.  I strongly recommend NOT using
> non-backbone OSPF areas as these add an extra layer of administrative
> complexity.  The only OSPF Area in use in any cluster should be Area 0.
> 
> 4.  As suggested in the SydneyWireless link above, LocFinder could calculate
> and supply a nodes' configuration information in an XML file, in
> human-readable format.  The node-owner could either enter this information
> manually, or software running on the node could parse the XML file and
> configure itself.
> 
> To unsubscribe: send mail to majordomo at wireless.org.au
> with "unsubscribe melbwireless" in the body of the message
> 
> 


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



More information about the Melbwireless mailing list