Subject: [GROW] I-D Action: draft-ietf-grow-blackholing-02.txt

From: [email-masked]
Date: Fri, 01 Jul 2016 04:07:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations of the IETF.

        Title           : BLACKHOLE BGP Community for Blackholing
        Authors         : Thomas King
                          Christoph Dietzel
                          Job Snijders
                          Gert Döring
                          Greg Hankins
	Filename        : draft-ietf-grow-blackholing-02.txt
	Pages           : 7
	Date            : 2016-07-01

Abstract:
   This document describes the use of a well-known Border Gateway
   Protocol (BGP) community for destination based blackholing in IP
   networks.  This well-known advisory transitive BGP community, namely
   BLACKHOLE, allows an origin AS to specify that a neighboring network
   should discard any traffic destined towards the tagged IP prefix.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-grow-blackholing-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-blackholing-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jay Borkenhagen <[email-masked]>
Date: Tue, 5 Jul 2016 10:24:31 -0400

My comments on draft-ietf-grow-blackholing-02:

- If the only purpose of the draft is to standardize the RTBH
  signaling community, wouldn't a better approach be to attempt to
  update RFC5635?

- Standardizing the RTBH signaling community is insufficient, as the
  party who wants to use it also needs to know where to signal:
  "in-band" with all the other route announcements, or via the
  dedicated ebgp-multihop session that some providers use?  The last
  time I checked, some providers do it one way, and some the other;
  some customers prefer upstreams who do it one way, some the other.

Yes, if you are under attack, I'm sure it's annoying to have to locate
the RTBH community of each of your upstream providers.  But I would
argue that it's critical for anyone using RTBH service from their
upstreams to know key aspects of each provider's RTBH implementation:

 - in-band or ebgp-multihop?

 - host routes only, or other ranges as well?

 - does the provider require pre-arrangement?

 - does the provider enforce a maximum duration of RTBH?

 - what does the provider do with RTBH announcements on prefix-lengths
    the provider says are out-of-scope?  e.g. if a provider says RTBH
    only on ipv4 /32 routes, yet the customer announces a /31 or a /24
    with the RTBH community?

Bottom line, I feel that standardizing the RTBH signaling community
does not bring enough benefit, and it sets the stage for customer
confusion and disappointment: "I sent the BLACKHOLE community to
upstream-X and to upstream-Y, and I got different results.  How come?" 

Thanks.

						Jay B.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Jul 2016 15:06:22 -0400

> upstream-X and to upstream-Y, and I got different results.  How come?"

Doesn't this presuppose that the community ends up making some action
happen by default? the draft skips talking about default-action (vendor
enforced action), and I think leaves the implementation up to the
provider/operator.

So... in the end your providerX may accept BLACKHOLE and 'blackhole' or
they may just 'drop on output port'.  While providerY may not do anything
with BLACKHOLE, just because they don't believe in that sort of magic.

This is the same situation as we have today: "I sent 7018:666, nothing
happened?" "Oh! you forgot to do the setup-dance with 7018..."
(s/7018/ANY/).

-chris

---

From: Jay Borkenhagen <[email-masked]>
Date: Thu, 7 Jul 2016 11:46:12 -0400

> happened?" "Oh! you forgot to do the setup-dance with 7018..."

Hi Chris,

I'm not presupposing any default action (and I agree router vendors
should not attempt any default action in this regard).

Here's the comparison I think should be made:

Today anyone who wants to use RTBH has a number of things they need to
know about their providers' implementations:

 - is RTBH supported?  if so:
 - what signaling community is used?
 - in-band or special ebgp-multihop session?
 - host-route only, or something different?
 - is any pre-arrangement necessary, and has it been taken care of?
 - will a maximum duration be enforced?

If this draft proceeds and is successful in standardizing a signaling
community, only one item has been removed from that list.  That
doesn't seem like a big win to me.

Thanks.

						Jay B.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Jul 2016 14:14:38 -0400

> doesn't seem like a big win to me.

ok, it's simpler, perhaps to know that you send XXX:YYY regardless, right?
For folk that have more than one upstream there are a slew of operators who
are less skilled at bgp policy than you or me... or (probably) most of grow@.
So making the multi-headed decision of:
  for peer X xxx:yyy
  for peer Y aaa:bbb
  for peer z ccc:ddd

could be more problematic. I think the aim is to just simplify that part,
how you transport the announcement (same bgp endpoint, new endpoint, hosts
only?) isn't a goal of the draft, and wouldn't (I think) be a goal for GROW
to standardize.

All this said, there's no reason that an operator needs to agree to use the
'well known' standard either.