To resume an old conversation:
>> I would suggest to make it more about leaks in general and not just
>> about security attacks (considering that many of the incidents with
>> leaks are mistakes and no targeted attacks).
>>
>
>that was (one) of my comments, yes. (to the authors)
I would very much like to understand route leaks more. Particularly what the
damage is that operators see.
Most of nanog complaints about route leaks is about massive route leaks causing
router overload and churn.
But that doesn't help understand the damage for a single prefix.
I can see:
cost/lost revenue and violation of business plan for the ISP
"poor user experience" for the traffic if the route is sub-optimal (like
the Google incident last Nov)
If the leaker network can not handle the leaked traffic, that poor user
experience could translate to unreachability. (OTOH, if the leaker network was
hugely provisioned, maybe better experience for user, but still cost/business
problem for ISP.)
I'd also like to understand more precisely what people consider a route leak.
To my understanding, a route leak is a violation of a constraint on an ISP's
export routing policy (arising from a business arrangement).
Is it usually the case that settlement free peerings include such constraints?
Are they explicitly stated in agreements or just generally understood? I hear
that people do not apply constraints on their peers, but I don't know if that
is because it is too hard or just not a concern.
--Sandy
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
