On 27 June 2019 16:31:27 BST, Mark Tinka <mark.tinka@seacom.mu> wrote:<br>><br>><br>>On 27/Jun/19 14:48, James Bensley wrote:<br>><br>>> That to me is a simple scenario, and it can be mapped with a<br>>> dependency tree. But in my experience, and maybe it's just me, things<br>>> are usually a lot more complicated than this. The root cause is<br>>> probably a bad design introducing too much complexity, which is<br>>> another vote for smaller PEs from me. With more service dedicated PEs<br>>> one can reduce or remove the possibility of piling multiple services<br>>> and more complexity onto the same PE(s).<br>><br>>Which is one of the reasons we - painfully to the bean counters -<br>>insist<br>>that routers are deployed for function.<br>><br>>We won't run peering and transit services on the same router.<br>><br>>We won't run SP and Enterprise on the same router as Broadband.<br>><br>>We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS,<br>>e.t.c.) on the same router where we terminate customers.<br>><br>>This level of distribution, although quite costly initially, means you<br>>reduce the inter-dependency of services at a hardware level, and can<br>>safely keep things apart so that when bits fail, you aren't committing<br>>other services to the same fate.<br>><br>>Mark.<br><br>Agreed. This is worked well for me over time.<br><br>It's costly in the initial capex out-lay but these boxes will have different upgrade/capacity increase times and price points, so over time everything spreads out.<br><br>Massive iron upgrades require biblical business cases and epic battles to get the funds approved. Periodic small to medium PE upgrades are nicer on the annual budget and the forecasting.<br><br>Cheers,<br>James.<br>