On 8/Feb/19 02:37, Brandon Martin wrote:
I've never been overly fond of the Ma' Bell style designs with humongous routers in centralized areas and L2-only haul out to the last-mile termination. The failure modes of such systems often result in hilariously large outages that are super visible publicly and put egg on peoples' face. A neighborhood being down is a little easier to manage from a customer relations POV, I think, and it's easy to make that happen with distributed L3 termination.
We don't do Consumer services, but for our Enterprise customers, we run IP/MPLS all the way into the Access and deliver services directly off those devices. Like you, we don't like centralizing services for the very same reasons that you state. That said, I've often considered different architectures if we did provide Consumer services - from centralized BNG's on a per-region or per-town basis, as well as de-centralized BNG's on smaller routers (back when the MX80 had just launched, but obviously not fit-for-purpose in 2019). Ultimately, I can't find a feasible way to deliver Consumer services scalably and inexpensively in a de-centralized model. But, I suppose, given the nature of the product and the ARPU, reasonable centralization for such customers is not a bad thing.
There are some smaller, somewhat cost-effective full-touch routers that can help bridge the gap between those two options, though. Juniper's MX104 and the Cisco ASR1k series are some reasonable options for that, but it'll definitely cost more than a cheap L3 switch for a given amount of bandwidth.
Our poison is the Cisco ASR920 and Juniper MX204. I am yet to find any other platforms with the size, density, capability and price for full IP/MPLS capability in the Access.
I do like to separate SMB and Resi traffic, but it's mostly for customer service reasons rather than technical reasons. That separation rarely entails separate equipment but rather just VLANs and PCPs, IP subnets, etc.
Many years ago, I did consider running both Consumer and Enterprise traffic on one router - and for purposes of pride, I'm sure the major vendors would like to boast that they could allow you to do this. But in practice, it's probably a bad idea... BNG's have too many moving parts, and for some platforms, there is actually special code optimized for BNG deployments that may have an impact on traditional Enterprise or Service Provider customers. So I would separate BNG's from regular edge routers.
Now if you want to sell DIA type services where you can offer full BGP tables, MPLS interconnection, etc., that's another matter. A need for IPv4 CGNAT may, as well, but things like 464XLAT, lw4o6, MAP, etc. can fix that up if you're willing to put some extra requirements on your CPE/RG.
We do all this in the Access on our ASR920's and MX204's (once we start deploying them).
If you're in a position where you want to or have to offer competitors access to your network to sell service directly to customers, that's also going to potentially really change the situation.
Why? Chances are they will require Ethernet access between their customer and their head-end, which is a typical scenario. Mark.