Early Review of draft-ietf-idr-large-community-06
review-ietf-idr-large-community-06-rtgdir-early-mcpherson-2016-11-14-00

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.