[MLB-WIRELESS] Revisiting OSPF

[David Ashburner]

Hi Dan,
I have read through your mail and the links. It seems that other people's 
experiences suggest that a multi-region OPSF configuration is too cumbersome 
for this type of network/inter-network.

I don't think the issue of administrative independance is all that great, in 
the context of being an ISP  on the internet you need isolation from other 
AS routing policies whereas in MW there is a sort of agreed policy 
(otherwise your not playing).  Probably a bigger concern here is  working 
out who needs to run a routing daemon and who doesn't.

A Client node say, a roaming laptop has no need for a daemon, it should 
receive routing information in the DHCP message it gets when connecting to a 
Node.  If it roams to another node then the new connection will update the 
routing information.

A node that has no dedicated links would also not need it.

A node that has one link could run BGP with the other end of the link being 
the neighbour.

A node that has multiple links would need to run the agreed routing 
depending on how tightly the cooperation with the other end(s) ( It may be 
BGP to both links or BGP to one and RIP to the other).

As suggested to you in the quagga forums, perhaps the best way to go would 
be to treat each node as an AS. When nodes establish links they agree to run 
BGP and communicate as neighbours, or they use OSPF / RIP / static routes 
and become a larger AS.

>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.

This is the real reason why OSPF is not going to cut it alone. Our network 
is going to grow as pools of connectivity that will coalesce over time. The 
suggested multiple AS with OPSF region 0 and BGP as two established AS join 
seems to be a good way of achieving connectivity.

>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.

This is where it gets messy. iBGP would mean each backbone node having  each 
other backbone nodedefined as a neighbour (they would have the same AS), 
there would potentially be hundreds of  nodes to the backbone.  I would 
think as our network gets better connected the backbone nodes are going to 
be obvious. Then they operators of these nodes would use OPSF internally as 
region zero of the backbone AS while continuing to use BGP to share routing 
information with their directly connected non-backbone neighbours.  Each 
backbone node owner would maintain their OPSF daemon using the agreed 
configuration and their locally connected edge Nodes via the configuration 
of their BGP daemon. This should be no mode difficult than maintaining the 
physical connections ( not too hard to provide a parameter like  neighbour 
10.10.1.65 as 23456).

>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.

agree 100%

>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.

Yep, you get it. I like the concept of a cloud of ignorance !!



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