On Thu, Jul 30, 2015 at 10:51:35AM -0400, Jeffrey Haas wrote: > On Wed, Jul 29, 2015 at 05:43:42PM +0000, Thomas King wrote: > > > On 28 Jul 2015, at 17:34, Jeffrey Haas <[email protected]> wrote: > > > One thing I'd recommend for the draft is explicit discussion about the > > > scope > > > of the community and its expected propagation characteristics. > > > > I just uploaded a revised version of the draft. It contains an > > overhauled section 3 (Operational Recommendations). Does this > > contain what you recommended? > > Things are better. As you note below you say: > > > > The simple > > > fact is that even with some implementations or operators who strip this > > > community themselves for scope, it'll leak. Plan for the leak > > > operationally. > > > > We did - we changed “3.2. Local Scope of Blackholes” so that a BGP > > speaker receiving an BGP announcement tagged with the BLACKHOLE > > community SHOULD add a NO_ADVERTISE, NO_EXPORT or similar > > communities. > > The issue we've had over the years is that the propagation communities > get stripped or failed to get added and leak.
We expect the receiving network to add propagation limiters, just like almost every RTBH implementation does today. > Part of the question is whether we should also have a stronger check: > If a route is tagged with blackhole, and it is more than one AS-hop away, > should we discard the route? (Or mark ineligible for selection.) > > I think my concern here is that someone marks an existing route with the > blackhole community and we can't readily determine whether the blackhole > behavior should be dropped or not. > > In the presence of RPKI ROA, it's easier to note that someone is > misoriginating a route and we can tell. But determining what to do seems > tricky. I generally agree with your assessment, but I'd like to take a slightly different angle: At 2914 we offer blackholing to customers, customers can signal to us that traffic to a destination should be dropped if 2914:666 is attached. With this draft I hope to standardize and replace the magic ntt-specific value with something that can be supported by more operators. I do not anticipate or expect changes in the BGP implementations we currently use in our network, nor would I want to wait for new IOS or JunOS to leverage well-known "BLACKHOLE". I'd merely add in the matching rules of our policy (next to 2914:666) that the well-known "BLACKHOLE" now also can trigger blackhole behaviour. Getting a well-known BGP community assigned or asking BGP implementators to treat BLACKHOLE routes differently, should maybe be separate drafts, the time scale of each being vastly different. > Please note that these criticisms are not specifically directed to > this draft. This is a set of known consequences of such blackhole > communities. Of course, acknowledged. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
