RE: few big monolithic PEs vs many small PEs

[<adamv0025 () netconsultings com>]

> Mark Tinka
> Sent: Thursday, June 27, 2019 4:31 PM
>
>
>
> On 27/Jun/19 14:48, James Bensley wrote:
>
> > That to me is a simple scenario, and it can be mapped with a
> > dependency tree. But in my experience, and maybe it's just me, things
> > are usually a lot more complicated than this. The root cause is
> > probably a bad design introducing too much complexity, which is
> > another vote for smaller PEs from me. With more service dedicated PEs
> > one can reduce or remove the possibility of piling multiple services
> > and more complexity onto the same PE(s).
>
> Which is one of the reasons we - painfully to the bean counters - insist that
> routers are deployed for function.
>
> We won't run peering and transit services on the same router.
>
> We won't run SP and Enterprise on the same router as Broadband.
>
> We won't run supporting services (DNS, RADIUS, WWW, FTP, Portals, NMS,
> e.t.c.) on the same router where we terminate customers.
>
> This level of distribution, although quite costly initially, means you reduce the
> inter-dependency of services at a hardware level, and can safely keep things
> apart so that when bits fail, you aren't committing other services to the same
> fate.
If the PEs are sufficiently small I'd even go further as to L3VPNs-PE vs L2VPNs-PE services etc...,  it's mostly 
because of streamlined/simplified hw and code certification testing.
But as with all the decentralize-centralize swings one has to strike the balance just right and weight the aggregation 
pros against too many eggs in one basket cons.

adam