Last Mile Design
mark.tinka at seacom.mu
Fri Feb 8 07:07:00 UTC 2019
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
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
We do all this in the Access on our ASR920's and MX204's (once we start
> 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.
More information about the NANOG