RTG-DIR REVIEW: draft-ietf-idr-large-community-08 Hello, 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 http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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 Summary: 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 document. Comments: 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 :-) Nits: None.