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

Request Review of draft-ietf-grow-blackholing
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-08-02
Requested 2016-06-29
Authors Thomas King, Christoph Dietzel, Job Snijders, Gert Doering, Greg Hankins
Draft last updated 2016-08-08
Completed reviews Genart Last Call review of -00 by Russ Housley (diff)
Genart Telechat review of -02 by Russ Housley (diff)
Secdir Last Call review of -00 by Paul Hoffman (diff)
Opsdir Last Call review of -00 by Susan Hares (diff)
Rtgdir Early review of -00 by Susan Hares (diff)
Assignment Reviewer Susan Hares 
State Completed
Review review-ietf-grow-blackholing-00-opsdir-lc-hares-2016-08-08
Reviewed rev. 00 (document currently at 03)
Review result Serious Issues
Review completed: 2016-08-08

Review
review-ietf-grow-blackholing-00-opsdir-lc-hares-2016-08-08

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