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