I learned from the shoulders of giants that multi-area OSPF is the right way to build networks when moving from the Core to the Distribution network.

The classic solution is to divide the network into areas of routers that are relatively related through topology or latency zones, enabling the small area network to converge quickly and only flood a single summary LSA with the result. This limits the risk inherent with link state protocols whereas link flaps could cause OSPF to rapidly execute Dijkstra SPF, leading to OSPF storms. This storm risk grows with the size of a particular area.

Lately, I've encountered engineers who run very large networks with everything in Area 0. They cite modern improvements to router CPUs that can handle mesh environments that widely exceed the guidance of up to 50 routers per area. A very important but secondary concern is the understanding by the staff required to maintain single area OSPF is a much lower bar. I believe that I've also heard about additional complexities with MPLS / LDP in multi-area OSPF.

I'd love to hear other's thoughts on this concept.

To be clear, this is the underlay for a BGP overlay that carries all of the MGMT and Customer routes.

Thanks Spudrageous,
Two reactions - (not criticisms!):

1. Most OSPF tutorials and most of the (lesser # of) deployments I've seen ignore redundancy! I.e., they have a single ABR between each area and Area 0. We are very focused on no single point of failure. For this, you can stick two ABRs between area 0 and area X but then, to steer bidirectional traffic over a preferred path (say fiber vs radio), you need to configure an area X tunnel through Area 0 between these two ABRs. Any discussion of OSPF areas should include a discussion of redundancy but it's seldom mentioned. That said, for historical reasons we ended up with four separate area zeros as private ASNs interconnected by eBGP and upstream with BGP confederation. So, we ended up with complexity in another form...

2. I can attest to modern routers easily handling larger networks. We have areas with 20 and 60 routers, but we also have one area with 147 routers and over 3000 OSPF routes. The routers are CCR1036, CCR1009, RB4011, plus a few residual RB3011 & RB2011 devices. In the 25+ years people have been deploying OSPF, router processors have gone from an 80 MHz PowerPC to quad ARM cores at 1.9 GHz with hardware off load (on the RB4011)! That's a non-trivial upgrade.

Our network with 147 routers runs one OSPF area zero with no problems. Adding a route at one edge is reflected on a router at a distant edge (8 hops) within one Winbox refresh interval (1 sec?) and we can force route changes by marking a core link passive and see no packet loss at a downstream client site.

That said, our stability may be helped by a script we developed in 2012 (for RouterOS 4) which still runs once a day at 6am on every router. It deletes (if present) and then recreates a set of high-cost static routes duplicating the current OSPF routes. This was critical for stability of our original OSPF network on RouterOS 4 on RB750UP routers in 2012. I haven't been able to prove these backup routes are ever invoked today, but we haven't deleted the script.

I'm definitely interested in hearing about other's experiences.

Hi Spudrageous

We are currently developing a GNS3 prototype for a multi-area OSPF network where OSPF will distribute PtP and Loopback addresses. iBGP will run on top of this to distribute customer subnets. With iBGP working we can also make use of BGP signaled VPLS and BPG VPN

You are correct the OSPF configuration is more complex with multiple areas, however, if you consider a single area at a time, then the complexity remains the same. The only routers that are more complicated to deal with would be the area border routers.

LDP protocol works, however we hit one snag, that might be useful for others to know about.
You should not summarize the entire area subnet on the ABR's, you should only summarize the subnet use for PTP addresses. Hence, your loopback addresses should be unsummarized in all areas. From this flows the logic that you need to create separate subnets for Loopbacks and PTP addresses in each area to make this possible.

In general I don't see the logic in saying the CPU's are more powerful therefore we can ignore best practice.
In the long-run efficiency will always be better. Or if we look at the flipside, creating code / config that is inefficient will eventually catch up with you.