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. 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-ix-bgp-route-server-08.txt Reviewer: Geoff Huston Review Date: 8 September 2015 IETF LC End Date: Intended Status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: The document is clear, and easily read. Sections 2.1 and 2.2 are consistent with a Standards Track specification document Section 2.3 appears to be more speculative in nature and the text is consistent with an informational document, but not necessarily consistent with a Standards Track specification. Major Issues: 2.3. Per-Client Policy Control in Multilateral Interconnection I am having a lot of difficulty understanding the role of this section in a standards track document. The section describes a problem of a route server exercising unilateral route policy selection, and thereby occluding potential routes from the route server's clients. The document then describes three potential approaches for addressing this issue: 2.3.2.1 Multiple Route Server RIBS Is there a reference for this approach? If not, then is this text intended to be the reference specification for multi-RIBs? I'm not entirely comfortable with this section as part of a Standards Track specification given the lack of a clear specification of this routing behaviour. The informal two paragraph description of the intended behaviour seems to me to be inconsistent with a standards track specification. 2.3.2.2.1. Diverse BGP Path Approach This references RFC6774, an Informational document. Given that the document subsequently states that "A route server SHOULD implement one of the methods described in Section 2.3.2 to allow per-client routing policy control without "path hiding"." then I am very surprised to see RFC6774 listed as Informative rather than Normative. It should be Normative. But then as its Informational, this becomes a downref in this document which the authors need to address. 2.3.2.2.2. BGP ADD-PATH Approach This references [I-D.ietf-idr-add-paths]. Same comment as above. The Standards track document is saying that a Route Server SHOULD implement one of three approaches where one is unreferenced, one is informataional and one is still a draft. I think this is a major impediment to the document's progress as a Standards Track document. Minor Issues: 1. Introduction, Second Paragraph: The unilateral assertion about scaling is perhaps over-doing it. The text should add a qualifier such as "in large exchanges" or "in some circumstances" so that the sentence is not interpreted as a universal condition, but one that arises as the number of peer sessions increases at an exchange