Last Call Review of draft-ietf-grow-large-communities-usage-06

Request Review of draft-ietf-grow-large-communities-usage
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-04-21
Requested 2017-04-07
Authors Job Snijders, John Heasley, Martijn Schmidt
Draft last updated 2017-04-18
Completed reviews Rtgdir Last Call review of -06 by Martin Vigoureux (diff)
Opsdir Last Call review of -07 by Jouni Korhonen
Genart Last Call review of -06 by Stewart Bryant (diff)
Genart Telechat review of -07 by Stewart Bryant
Secdir Last Call review of -06 by Klaas Wierenga (diff)
Assignment Reviewer Stewart Bryant
State Completed
Review review-ietf-grow-large-communities-usage-06-genart-lc-bryant-2017-04-18
Reviewed rev. 06 (document currently at 07)
Review result Almost Ready
Review completed: 2017-04-18


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-grow-large-communities-usage-??
Reviewer: Stewart Bryant
Review Date: 2017-04-18
IETF LC End Date: 2017-04-21
IESG Telechat date: Not scheduled for a telechat


This is mostly a well written document, although unfortunately there are a number of matters that really need to be looked at.

Major issues:


   Examples and inspiration for operators to use BGP Large Communities.

SB> Even if you just copy the Introduction, the Abstract should really be expanded
SB> to help the reader understand whether or not they want read the RFC
SB> or if they had read it what it was about.


5.  Security Considerations

   Operators should note the recommendations in Section 11 of BGP
   Operations and Security [RFC7454].

SB> You do not address the question of whether there are new considerations, or considerations
SB> that are of increased importance? Is there is text somewhere
SB> that discusses the integrity and synchronization of the parameters
SB> and any consequences that arise?


Minor issues:

2.2.  Action Communities

   Action Communities are added as a label to request that a route be
   treated in a particular way within an AS.  The operator of the AS
   defines a routing policy that adjusts path attributes based on the
   community.  For example, the route's propagation characteristics, the
   LOCAL_PREF (local preference), the next-hop, or the number of AS_PATH
   prepends to be added when it is received or propagated can be

SB> Although these are well known to the target audience, I think you
SB> need some references in the above para.

Nits/editorial comments: 

6.  IANA Considerations


SB> A little briefer than normal.