[Idr] RtgDir review: draft-ietf-idr-ix-bgp-route-server-08.txt

[Geoff Huston <[e-mail]>]

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