ietf
[Top] [All Lists]

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

2016-06-28 10:28:32
On Tue, Jun 28, 2016 at 11:17 AM, Gert Doering <gert(_at_)space(_dot_)net> 
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

<Prev in Thread] Current Thread [Next in Thread>