Re: [GROW] Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Tue, Jun 28, 2016 at 11:17 AM, Gert Doering <gert@xxxxxxxxx> wrote:
Hi,

On Tue, Jun 28, 2016 at 11:11:30AM -0400, Christopher Morrow wrote:
> ???Perhaps Nick is reacting to language like:
> "???
>  This well-known advisory transitive BGP
>    community, namely BLACKHOLE, allows an origin AS to specify that a
>    neighboring IP network or IXP should blackhole a specific IP prefix.
> ???"???
>
​​<sorry about these wonky characters>​
> ???which could be cleaned up a bit like:
> "???This well-known advisory transitive BGP
>    community, namely BLACKHOLE, allows an origin AS to specify that a
>    neighboring IP network or IXP PARTICIPANT should blackhole a
>    specific IP prefix."

Well, the intention *is* that "if the IXP supports black-holing, please do".


​yup.​

 
In implementations like DECIX', the neighbouring IXP participant does not
have to do anything in particular, except "accept the prefix with the
black-hole nexthop".


Maybe more along the lines of

  This well-known advisory transitive BGP
    community, namely BLACKHOLE, allows an origin AS to specify that a
    neighboring IP network or IXP that has appropriate mechanisms in place
    is requested to blackhole a specific IP prefix.


​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 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')​

 
Gert Doering
        -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]