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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 29, 2016 at 01:30:49PM +0100, Nick Hilliard wrote:
> The second major area of concern I have about this proposal is the
> transitive nature of the bgp community.

I thought Section 3.2 provides enough detail on scoping routes tagged
with BLACKHOLE, however with your concern and the following in mind:

This draft intends to unify the wild variety of blackholing communities
which exist in the wild by providing a single Well-known codepoint, see
bottom of [1] for an incomplete list.

I do not think it is feasible to mandate new behaviour (like
automatically adding a NO_EXPORT community) in this draft. It is up to
the network operator to decide when and where to honor a blackhole
community and when not to honor it.

Automatically adding NO_EXPORT (or any of the other scope limiting
Well-known communities) is likely to lead to implementation difficulty
for operators when prefixes with a blackhole community attached need to
be redistributed to some sort of sibling network.

So, with your concern and the above in mind:

Should it be somehow clarified that router vendors are not supposed to
implement mechanisms, which are by default enabled, that discard traffic
for BLACKHOLE'ed prefixes?

Just like the deployment of honoring the NOPEER [rfc3765] community is
100% driven by the operator, out of the box the vendor implementations
do nothing with the community except transit it. 

Kind regards,

Job

[1]: https://www.ietf.org/mail-archive/web/ietf/current/msg98740.html




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]