On Fri, Jul 1, 2016 at 7:40 AM, Nick Hilliard <nick@xxxxxxxxxx> wrote:
Job Snijders wrote:
> To address the latest concerns, draft-ietf-grow-blackholing-02 has been
> posted.
>
> Executive summary:
>
> - Changed intended status from STD to INFO
> - Added section 4 "Vendor Implementation Recommendations"
> - Simplify the security section
> - Clarify in introduction that this is about destination based
> blackholing
Job,
Sorry, but this update does not address the concerns raised about
clarifying the behavioural semantics of this flag. It's also not clear
why the security warning relating to denial of service attacks was removed.
first noting that it'd be helpful if you have concerns to suggestions that you send text that might be used to address them. Playing 'bring me a rock' is not fun for anyone.
As to the denial of service wording removal/change, i thought the change was actually positive because it removed a bit of ambiguity "if a network offering blackholing is traversed" only really applies if that network:
1) hears the prefix with the community
2) is configured to do something with that announcement
To back up a bit in the conversation I viewed the draft/document as doing two specific things:
1) reducing operational complexity between consenting bgp speaking adults
1) reducing operational complexity between consenting bgp speaking adults
2) letting operations staff decide how/where/what to do with a prefix seen from their peer(s).
I think a community today is used (many actually) to signal requested treatment of a prefix across an AS boundary (rfc1998 for example), operators on both sides of the peering decide what to add to a prefix on exit, and what to do with the additions on receipt. I expect peers to be consenting adults and to not shoot themselves in the foot...
I would expect this proposed community to be used along with adding no-export on receipt at the peer, because sending the community more broadly isn't as helpful.
As to the issue with authenticating the announcement, the draft discusses the fact that communities being 'protected' are explicitly a non-goal of the coming protection mechanisms proposed for BGP. I don't see that changing, because communities are grouping mechanisms used inside networks, they may not survive across AS boundaries, and they almost certainly are added inside networks for locally significant reasons.
I suggest that if there are objections to the current version we get some text on-list where we can hash out next-steps, if there's no text offered I think we all vote to move this document forward.
-chris