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

[Nick Hilliard <[e-mail]>]

Geoff, ADs,

thanks for your review.

>From a technical correctness point of view, the text in section 2.3 is
indeed "speculative".  It's not possible within the scope of this document
to change rfc6774 to be standards track or to get the add-paths draft to
rfc stage.  You're also correct that there is no formal description about
how to handle multiple loc-ribs, even though there are several of
production implementations which do this.

Having said that, the authors would feel uncomfortable about writing a
document about how to approach an RS implementation without flagging path
hiding and its potential workarounds.  Production IXPs tend to view this as
being an important part of RS implementations.

We've taken your comments on board and have explicitly noted that section
2.3 and all its subsections are informational only.  The rfc2119 language
in this section has also been toned down to remove any implication that the
section could be interpreted as normative.

Separate to this, the wording has been changed for the minor issue.

Draft -09 has now been published; hopefully this will address the concerns
you raised.

Nick

On 08/09/2015 00:59, Geoff Huston wrote:
> 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
>   
> 
> 
> 
> 
>   
>   
>   
> 
> 
> 


-- 
Network Ability Ltd. | Chief Technical Officer | Tel: [phone]
52 Lower Sandwith St | INEX - Internet Neutral |
Dublin 2, Ireland    | Exchange Association    | Email: [e-mail]