On Fri, Jul 1, 2016 at 7:40 AM, Nick Hilliard <nick(_at_)foobar(_dot_)org>
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
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