Last Call Review of draft-ietf-grow-blackholing-00
review-ietf-grow-blackholing-00-opsdir-lc-hares-2016-08-08-00

I have been selected as the Routing Directorate and the Operational/NM
directorate reviewer for this draft. The Routing Directorate seeks  to review
all routing or routing-related drafts as they pass through IETF last call and
IESG review, and sometimes on special request. The Operations Area directorate
seeks to review all documents to determine if protocol mechanism are deployable.

For details on the Routing Directorate, please see



​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

.

For details on the Operational, please see RFC5706 and

https://svn.tools.ietf.org/area/ops/trac/wiki/Directorates

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.

Document:



draft-name-version

.txt



Reviewer: your-name



Review Date: date



IETF LC End Date: date-if-known



Intended Status: copy-from-I-D

·



Summary:

 I have a major and minor concerns about this document that should be resolved
 prior to publications.  I have provide the highlights of these issues, but I
 am willing to help the authors quickly craft changes to their draft.  This
 community is useful to BGP deployments.



Major:

·



Interaction of BGP Blackhole community with:  BGP Flow Specification
Communities that provide actions (RFC5575 and additional filters and actions
being specified in IDR (draft-ietf-idr*flowspec*).

·



BGP error actions based on RFC7606.

Minor

·



The document does not indicate whether combining ROA (RFC6483) plus this BGP
community would resolve the concerns that the community comes from the
authorized origin of the prefix that will be blackholed.  Sections 3.3 and 6
should be altered to provide the additional details on this point.

·



 Operational issues should cover whether this can be used in a IXP and Data
 Center.

Comments:

Please supply an overview of the draft quality and readability.

Include anything else that you think will be helpful toward understanding your
review.

Minor Issues:

·



[

RTG-DIR] The document does not indicate whether combining ROA (RFC6483) plus
this BGP community would resolve the concerns that the community comes from the
authorized origin of the prefix that will be blackholed.

[OPS-DIR]:  The different deployment scenarios for BGP are not considered in an
operational section. These scenarios include (but are not limited to):  a)
provider bgp, b) private vpn bgp, c) Data Center BGP, and d) IXP bgp.

RFC minor issues

 Please reference RFC 1997 in section 3.2 in the first sentence.   Pick one
 solution (NO_ADVERTISE or NO_EXPORT].   NO_ADVERTISE is a stronger restriction.

 Please reference RFC4271 as the main BGP specification.  Change initial BGP
 reference outside of the abstract to include this reference.

NITs

·



Abstract  “namely BLACKHOLE, allows” to “named BLACKHOLE which allows”

·



Section 3.3 – “it has been observed” – is a very vague statement.  It need to
be clarified by where it is observed.

o



Alternative” “It has been observed in BGP data records (reference)” or “It has
been observed in provider networks running BGP”>

Sue Hares