BLACKHOLE community RFC7999

[Ondrej Zajicek]

On Thu, Oct 20, 2016 at 10:51:21AM -0500, Job Snijders wrote:
> On Thu, Oct 20, 2016 at 05:35:43PM +0200, Clemens Schrimpe wrote:
> > >> Just FYI: https://www.rfc-editor.org/rfc/rfc7999.txt
> > >> I guess this feature deserves to be implemented.
> > > 
> > > Oh, sure. We plan to implement it.
> 
> RFC 7999 says:
> 
> 4.  Vendor Implementation Recommendations
> 
>    Without an explicit configuration directive set by the operator,
>    network elements SHOULD NOT discard traffic destined towards IP
>    prefixes that are tagged with the BLACKHOLE community.  The operator
>    is expected to explicitly configure the network element to honor the
>    BLACKHOLE community in a way that is compliant with the operator's
>    routing policy.

You are right. I already discussed this with Thomas King. In contrast to
RFC 1997 well-known communities, which are processed by default,
BLACKHOLE community should be ignored by default.

So it is a question what really means to implement RFC 7999.

We could simply add constant, say BC_BLACKHOLE, with value (65535, 666).

We already have option 'interpret communities' (enabled by default),
which can be used to disable processing of RFC 1997 well-known
communities (e.g., NO_EXPORT).

We could add option 'interpret blackhole' (disabled by default),
which could be used to enable RFC 7999 behavior. But it is
a question whether that would be more useful than simply using:

if BC_BLACKHOLE ~ bgp_community then dest = RTD_BLACKHOLE;

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20161020/2bc5521f/attachment.asc>