On Sat, Aug 13, 2016 at 01:18:20PM +0100, Nick Hilliard wrote: > Job Snijders wrote: > > Nick understands the intent of the draft very well: honoring this > > community is optional and usually (but not always) part of a commercial > > supplier-customer agreement. > > > > We changed the text to the following: > > > > """ BGP speakers in a bilateral peering relationship using the > > BLACKHOLE community MUST only accept and honor BGP announcements > > carrying the BLACKHOLE community under the two following conditions: > > > > o the announced prefix is covered by an equal or shorter prefix > > that the neighboring network is authorized to advertise > > o the receiving party agreed to honor the BLACKHOLE community on > > the particular BGP session > > > > In topologies with a route server or other multilateral peering > > relationships, BGP speakers SHOULD accept and honor BGP announcements > > under the same conditions.""" > > the changes in -03 doesn't fully address this issue either. I've > created two github pull requests for suggested text updates: > > > https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/1/files
While I like the simplity of the sentence, there already is text which makes it clear that everything is "MAY" or "OPTIONAL": Line 24: "well-known advisory" https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L24 Line 139: "this community as an advisory qualification to drop" https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L139 Line 146-147: "Accepting and honoring the BLACKHOLE community, or ignoring it, is a choice that is made by each operator." https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L146-L147 Line 149-150: "use of the BLACKHOLE community MUST be agreed upon by the two networks before advertising it" https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L149-L150 Line 156 "it MAY announce an IP prefix" https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L156 Line 205: "the receiving party agreed to honor the BLACKHOLE community on the particular BGP session" https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/blob/master/draft-ietf-grow-blackholing-03.txt#L205 Adding yet another line about the optional nature seems redundant. So, I'm going to have to decline this specific suggestion in its current form, however if you have a proposal to introduce the word OPTIONAL in one of the above sentences we can consider it. > > https://github.com/draft-ietf-grow-blackholing/draft-ietf-grow-blackholing/pull/2/files > > The second adds a note to say that both the receiving and the sending > party should explicitly filter out more-specifics unless they're tagged > with BLACKHOLE. I would be in favour of seeing this noted in the > security considerations section, as it is a security related problem. I'm not comfortable adding this line, because the moment the BLACKHOLE community is not attached to a prefix, its out of scope for this document. One example: NTT for instance announces longer than /24 customer prefixes to its customers, if a valid route object exists - these more-specifics do not carry the BLACKHOLE community, but they are legitimate route announements. Maybe I am misunderstanding the intention of your proposed change - can you elaborate? Are you sure that the problem case you describe isn't already covered by the existing text? Thank you for your time and review, much appreciated. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
