Re: 1GE L3 aggregation

[Saku Ytti <saku () ytti fi>]

On 18 June 2016 at 18:37, James Jun <james.jun () towardex com> wrote:

Hey,

> 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.

This is weak rationale. The flip side of this rationale is that the
centralised aggregation, when attacked will bring down all the 'remote
sites'. Now which is more typical reason for outage, I don't know. But
of course the L3 situation can be policed in many places, you can
police it at network ingress, you can police it between upper level
aggregation and downstream aggregation.

I do understand the centralised aggregation, particularly like Baldur
explained if only very few customers will have IP transit, it's silly
to pay 5k-10k for full DFZ box, when you can probably get L2VPN box
for hundreds of bucks. In my case almost all of the customers would
have IP transit with full BGP.
But I do think, that if L3 to the edge had no commercial problems,
people would universally choose to do it. L2VPN is just workaround to
a commercial problem. Sometimes (residential access) to a technical
problem (how do I share my IPv4 space effectively).

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

I'm not really looking cheap pipeline box, I'm looking
run-to-completion NPU box with 1GE edge. The Huawei NE20E-S2F proposal
was fine, ASR9001 and MX104 are not ok (Both having less than beefy
control-plane, while forwarding plane in all is fine). ALU SR would be
fine, but I have specific need for configuration management not today
supported by TimOS.

But even higher-end kit usually have plenty of vectors to do
collateral damage, particularly if attacker is one of the customers.
For example in ASR9k, you can't really protect customerA from
customerB doing eBGP/ICMP/ARP flood, customerB does not have to be
malicious, might be just internal L2 loop causing high rate of packets
at provider port.

-- 
  ++ytti