Skip to main content

Early Review of draft-ietf-idr-large-community-06

Request Review of draft-ietf-idr-large-community
Requested revision No specific revision (document currently at 12)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-11-13
Requested 2016-11-03
Authors Jakob Heitz , Job Snijders , Keyur Patel , Ignas Bagdonas , Nick Hilliard
I-D last updated 2016-11-14
Completed reviews Rtgdir Early review of -06 by Geoff Huston (diff)
Rtgdir Early review of -06 by Danny R. McPherson (diff)
Opsdir Last Call review of -11 by Rick Casarez (diff)
Genart Last Call review of -11 by Robert Sparks (diff)
Secdir Last Call review of -11 by Vincent Roca (diff)
Assignment Reviewer Danny R. McPherson
State Completed
Request Early review on draft-ietf-idr-large-community by Routing Area Directorate Assigned
Reviewed revision 06 (document currently at 12)
Result Has issues
Completed 2016-11-14
RTG-DIR REVIEW: draft-ietf-idr-large-community-08


I have been selected as the Routing 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 (as is the case here). The purpose of the 

review is to provide assistance to the Routing ADs. For more information 

about the Routing Directorate, please see

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-ietf-idr-large-community-08.txt

Reviewer: Danny McPherson

Review Date: November 14, 2016

Intended Status: Standards Track


I have no major concerns with the content of this document and believe 

it is ready for publication.  Some minor comments are provided below, 

although only with the intention to inform the authors, WG, and routing 

ADs during their deliberations with regard to the publication of this 



I believe the draft is technically sound and addresses an immediate 

operational need in a pragmatic manner.

Major Issues:

I have no “Major” issues with this I-D, I believe it is ready for 

publication as a Standards Track RFC.

Minor Issues:

S.2: Regarding the change in the -08 version to "MUST NOT" in "Duplicate 

BGP Large Community values MUST NOT be transmitted", I agree with John 

Scudder's November 14th email to the IDR WG on this topic, connecting it 

to RFC 2119 definitions and Postel's law.  I believe MUST NOT is a good 

statement, particularly when considering implications of lazy 

implementations doing things such as including duplicates when creating 

aggregates such as outlined in S.3.  Upon further consideration, to 

Peter Hessler's question on the same mailing list thread, perhaps RFC 

1997 and 4360 communities SHOULD have such a restriction - for the sake 

of global routing system hygiene, at least!

S.3: Regarding an aggregate inheriting all the BGP Large Communities 

from all of the aggregated routes, it would seem to me such an 

instruction may result in unintended operational impacts where regional 

or other intra-AS and routing policy functions based on community are 

promoted to the aggregate and trigger undesirable behavior.  Operators 

should certainly be aware of the potential implications of this in their 

operational environments.

S.7: I believe the reference to S.11 of RFC 7454 is appropriate, 

although upon rereading I am not sure I agree with the advice of that 

BCP.  Specifically, suggesting that communities not be scrubbed on 

ingress (other than to enforce "high order bit" feasibility) leads to 

more unique path attributes that result in systemic effects (e.g., less 

efficient update packing, more memory consumption and unnecessary global 

routing system state, path churn resulting from community changes, 

etc..).  Of course, that's well outside the scope of this document but 

this will certainly have implications related to those practices, as 

well as the default "scrubbing" practices by many operators.

S.8: The editors call for the RFC Editor to remove section 8 

"Implementation Status" before publication.  I believe there is value in 

keeping this section in the document in order to memorialize the current 

implementation and operational status of the proposal, unless the 

intention is to create an external "Implementation Report" associated 

with Large Communities now or at a later time when progression along the 

Standards Track is desired.

S.11: That's a solid list of acknowledgements there, it may be simpler 

to list who didn't contribute :-)