Early Review of draft-ietf-idr-large-community-06
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.
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.
I have no “Major” issues with this I-D, I believe it is ready for
publication as a Standards Track RFC.
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
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 :-)