Dear all,
On Tue, Jun 28, 2016 at 11:27:52AM -0400, Christopher Morrow wrote:
that seems reasonable, though I don't think it necessarily addresses
Nick's issue that: "YIKES! please don't mention that IXP's can/will do
this sort of function"
I still question the validity of Nick's concern. Since when do LEA read
RFCs/drafts like draft-ietf-grow-blackholing and then conclude "oh, this
RFC says that blackholing at IXPs can't be done, alrighty then, we'll
show ourselves out!".
LEAs will request what LEAs will request, regardless of technical
feasibility or IETF's acknowledgement/denial a facilitating mechanism
exists.
I think even in the cases where the IXP may add the right community
and reset nexthop, the participants have to actually accept these
prefixes and agree with the IXP about the nexthop, and throw away the
traffic destined to the prefix(es).
You could make an ixp have a next-hop internal to the fabric which was
the discard, but I dont' think that solves the larger problem of: "oh,
our ixp fabric is full of packets :(" since the participants would
still be putting packets onto the fabric.
maybe that's not the problem which is trying to be solved though
(fabric full, instead of 'participant interface is full')
Some IXPs can do actual blackholing inside their fabric, a mechanism
which does _not_ require any of the IXP participants to participate or
adjust their local routing policy to honor the BLACKHOLE community. I've
described such a non-cooperative mechanism on the NANOG mailing-list and
I know of one IXP which has implemented this. (This is different from
DE-CIX's current implementation.)
Already today, the reality is that some IXPs can and will blackhole
traffic at the request of a participant, and some IXPs can't (vendor
limitations) or won't (miscellaneous concerns) blackhole traffic. This
draft does not change any of that.
Kind regards,
Job