1GE L3 aggregation

Sat Jun 18 15:37:11 UTC 2016

On Sat, Jun 18, 2016 at 01:04:49PM +0200, Mark Tinka wrote:
>
> Centralizing is just horrible, but that's just me. The goal is to make
> all these unreliable boxes work together to offer a reliable service to
> your customers, so making them too inter-dependent on each other has the
> potential to that away in the long run.
> 

One issue with pushing IP transit (L3-wise) with small boxes down to the
metro is that if a particular customer comes under attack, any DDoS in
excess of 10-30 Gbps is going to totally destroy the remote site down to
the floor and then some, until NOC intervenes to restore service.

A Big Expensive Router at head-end site fed with big pipes to your IP core
just needs a subscriber line rate policer configured on the customer EVC
off the NNI facing your metro transport network, largely protecting your
metro POP during an attack.

There are also issues with control-plane policing (or limited options
there of) with some of these low-end platforms.

> 
> We push IP/MPLS all the way into the Metro-E Access using a team of
> Cisco ASR920's and ME3600X's. The value of being able to instantiate an
> IP service or BGP session directly in the Metro-E Access simplifies
> network operations a great deal for us. Needless to say, not having to
> deal with eBGP Multi-Hop drama does not hurt.

BGP Selective Download has its own drawbacks too--in that, it's largely
meant to be used on single-tailed environment with FIB only having single
point of egress.

Consider a topology where an ASR920 in the metro is dual-homed to two 
peering sites using variably distant dark fiber (say 30km to Site A,
90km to Site B), with IGP costs configured to conform to fiber distances.

How will you guarantee that the best-path that ASR920 chooses for your
customer taking full table to be actually congruent with the box's
real forwarding path?  Your 920 may choose site A as best-path, only
to see FIB-programmed default route to force it out on site B.  If you're
doing active-standby on your fiber uplinks, then it would not be an issue;
or may be in metro environment where latency differences are minimal (<1ms),
you probably don't care in practice to be bothered with that.

Yes, there are some operational complexities and issues with L2vpn'ing
customers to head-end router -- such as, link-state propagation needs to
be properly validated; and now you're burning two ports instead of one,
one at the terminus, one at the access, doubling SPOF and maintenance
liabilities.

At the end of the day, it's lack of full-featured ports at reasonable cost
that drive centralization to head-ends.  Spamming Small Expensive Routers
(ASR9001/MX104) in every small metro site doesn't scale (btdt myself), but
neither is hacking up BGP to work on platforms that aren't really meant to
function as heavy L3 routers (e.g. ASR920, ME3600), IMHO.

James