Subject: Re: [GROW] New Version Notification for draft-ymbk-grow-blackholing-00.txt

From: Thomas King <[email-masked]>
Date: Wed, 1 Jul 2015 17:21:29 +0000

Hi Job et all,

> On 26 Jun 2015, at 21:27, Job Snijders <[email-masked]> wrote:
> 
> On Fri, Jun 26, 2015 at 06:27:23PM +0000, Thomas King wrote:
>>> Another remark, should you decide to rename BLACKHOLEIXP to just
>>> BLACKHOLE, you might want to replace the references to "IXP" throughout
>>> the document and make it more general.
>> 
>> I am not sure if a more general approach (= ISP / transit environment)
>> makes lots of sense given RFC 3882.
> 
> Can you elaborate what the conceptual difference would be between a
> transit network and an IXP Route Server in this context? RFC 3882 does
> not define any well known community.

I mean that for transits RFC 3882 describes how blackholing can be configured. Many transits already provide a BGP community in order to trigger blackholing. Based on the slightly recommendation of this RFC 65001:666 or variations are often used. So, here an already working solution is available.

In the IPX environment the concept of blackholing is relatively new. So, we started thinking about standardising the triggering approach.

> Whether packets are discarded inside the IXP fabric or somewhere in the
> Transit provider's fabric^Wmagic.. I don't see much of a difference.

This is fine with me. If people stand up and say the proposal should be extended to transits I am more than happy to assist.

> In section 2:

…

> One could consider changing it to:
> 
>    "The semantics of this attribute is to allow a network to interpret
>    the presence of this community as an advisory qualification to drop
>    any traffic being sent towards this prefix."
>    (of course the rest of the document would also need some updating)
> 
> For years IP networks have offered blackhole services to their
> customers, much like some IXPs are now starting to do. One could argue
> that a standardized blackhole community is beneficial, in the spirit of
> the NOPEER community. Today NTT uses 2914:666 while Level3 uses
> 3356:9999, if multi-homed networks only need to remember 1 community,
> that might be easier. 

Ok.

So, do you want to help me extending the proposal? My intention is to have the proposal ready until the cut-off date. Do you think we can make it?
Anybody else wants to join?

Best regards,
Thomas

---

From: Geoff Huston <[email-masked]>
Date: Mon, 20 Jul 2015 19:05:50 +0200

Comment at the mic from today’s GROW session:

Please be mindful of “prior art” (as Joel Jaggeli described it) regarding the use of AS65535.

RFC7300 http://tools.ietf.org/html/rfc7300 which talks about the use of communities of AS65535. You may
want to consider what community you want to use in your draft in the light of the comments in this RFC.

thanks,

  Geoff

---

From: Jon Mitchell <[email-masked]>
Date: Thu, 23 Jul 2015 13:23:07 +0200

> On Jul 20, 2015, at 7:05 PM, Geoff Huston <[email-masked]> wrote:
> 
> RFC7300 http://tools.ietf.org/html/rfc7300 

I believe this draft's use of well known community assignment is inline with RFC7300 comments and the correct FCFS space of the registry but a reference to 7300 may be useful if the text in section 4 is planned to remain post publication.

-Jon

---

From: Thomas King <[email-masked]>
Date: Thu, 23 Jul 2015 13:05:43 +0000

> On 23 Jul 2015, at 13:23, Jon Mitchell <[email-masked]> wrote:
> 
> 
> 
> 
Full-Ack, I already added the RFC as reference.

Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 28 Jul 2015 11:34:24 -0400

> I believe this draft's use of well known community assignment is inline with RFC7300 comments and the correct FCFS space of the registry but a reference to 7300 may be useful if the text in section…

I didn't make it to the grow session, but I'm also supportive of this
becoming a well-known community.

One thing I'd recommend for the draft is explicit discussion about the scope
of the community and its expected propagation characteristics.  The simple
fact is that even with some implementations or operators who strip this
community themselves for scope, it'll leak.  Plan for the leak
operationally.

-- Jeff

---

From: Thomas King <[email-masked]>
Date: Wed, 29 Jul 2015 17:43:42 +0000

> On 28 Jul 2015, at 17:34, Jeffrey Haas <[email-masked]> wrote:

…

> of the community and its expected propagation characteristics.

I just uploaded a revised version of the draft. It contains an overhauled section 3 (Operational Recommendations). Does this contain what you recommended?

> The simple

We did - we changed “3.2. Local Scope of Blackholes” so that a BGP speaker receiving an BGP announcement tagged with the BLACKHOLE community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar communities.

Best regards,
Thomas

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 30 Jul 2015 10:51:35 -0400

Thomas,

> We did - we changed “3.2. Local Scope of Blackholes” so that a BGP speaker receiving an BGP announcement tagged with the BLACKHOLE community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar communit…

The issue we've had over the years is that the propagation communities get
stripped or failed to get added and leak.

Part of the question is whether we should also have a stronger check:
If a route is tagged with blackhole, and it is more than one AS-hop away,
should we discard the route? (Or mark ineligible for selection.)

I think my concern here is that someone marks an existing route with the
blackhole community and we can't readily determine whether the blackhole
behavior should be dropped or not.

In the presence of RPKI ROA, it's easier to note that someone is
misoriginating a route and we can tell.  But determining what to do seems
tricky.

Please note that these criticisms are not specifically directed to this
draft.  This is a set of known consequences of such blackhole communities.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Thu, 30 Jul 2015 17:03:02 +0200

On Thu, Jul 30, 2015 at 10:51:35AM -0400, Jeffrey Haas wrote:
> > I just uploaded a revised version of the draft. It contains an
> > overhauled section 3 (Operational Recommendations). Does this
> > contain what you recommended?
> 
> > We did - we changed “3.2. Local Scope of Blackholes” so that a BGP
> > speaker receiving an BGP announcement tagged with the BLACKHOLE
> > community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar
> > communities.
> 
> The issue we've had over the years is that the propagation communities
> get stripped or failed to get added and leak.

We expect the receiving network to add propagation limiters, just like
almost every RTBH implementation does today.

> misoriginating a route and we can tell.  But determining what to do seems

I generally agree with your assessment, but I'd like to take a slightly
different angle: At 2914 we offer blackholing to customers, customers
can signal to us that traffic to a destination should be dropped if
2914:666 is attached. With this draft I hope to standardize and replace
the magic ntt-specific value with something that can be supported by more
operators.

I do not anticipate or expect changes in the BGP implementations we
currently use in our network, nor would I want to wait for new IOS or
JunOS to leverage well-known "BLACKHOLE". I'd merely add in the matching
rules of our policy (next to 2914:666) that the well-known "BLACKHOLE"
now also can trigger blackhole behaviour.

Getting a well-known BGP community assigned or asking BGP implementators
to treat BLACKHOLE routes differently, should maybe be separate drafts,
the time scale of each being vastly different.

> Please note that these criticisms are not specifically directed to
> this draft. This is a set of known consequences of such blackhole
> communities.

Of course, acknowledged.

Kind regards,

Job