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@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."