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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
