Having a Tiered Architechture is a best practise, having said that now all sizes of networks would need one.

Considering the capacity of the routers now, size becomes the major criteria for having a tiered arch.

The reason for this is per pop the agregation/PE routers may connect to a minumum of 2 locally situated P routers

for redundancy. In turn the P routers can mesh out with other P routers of different regions or PoP's.

Considering the above situation if you had more than 2 PE in a PoP then it creates the classic mesh problem of n(n-1)/2.

Also its not a good idea to to make one of the existing PE's the PE/P routers are other PE's in the same PoP use them as P.

As this in case of a failure this would reduce the PoP availability and give you a low Availability figure (As this becomes more like systems in series rather than parallel which leads to lower availability numbers)

However if you dont have more than 2 PE'2 per PoP or if you can factor the costs for a mesh between the PE's/ or providing alternate paths per PE independent of other PE in the PoP then you can conisder going for PE/P design. MPLS TE or FRR shoudl not modfy you design decision, as it merely an overlay on you physical topology. So till you routers have an alternate path its feasible to deploy and utlize TE and FRR.

Now coming to the availability number calculation, if factors in an array of components, generally the 5' 9's figure is given per PoP.

Its impossible to quote a 5'9's figure per system. Hence its given per PoP where the systems are built in parallel to each other rather than in series ( this means that one failure can lead to failure of the other system). In short its an aggregate number of the availability of all the functional compoents put together for a pop. Which can range from the power source to line cards on each device.

The formula for each each system availability is Av = MTBF / (MTBF + MTTR) where MTBF stands for Mean Time Between Failure and MTTR stands for Mean Time Between Repair. Do note that these figure merely represent an approximation for any given device and can or canot be true in real life, as the MTBF for IOS can be quite unreliable and is genreally never factored or the MTTR for hardware needs depends on how much time is spent on troubleshooting or even discovering its a hardware failure when the failure is not explict enough.

Also the way your operations work is a big factor for MTTR as the available spares or the receipt of spares do count in this.

To summarize, these things work on a case to case basis, but considering the above points you can very well decipher an answer for your requirement.

HTH-Cheers,

Swaroop