> 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
