Early Review of draft-ietf-idr-bgp-optimal-route-reflection-11
review-ietf-idr-bgp-optimal-route-reflection-11-rtgdir-early-ceccarelli-2016-06-23-00

Hello,



I am the Routing Area Directorate member that was assigned the QA review of
draft-ietf-idr-bgp-optimal-route-reflection.



If you’re not familiar with the QA review process please see:

https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa



BR

Daniele



-



General comment:

The draft is understandable and does not require any major modification in
addition to the minor edits and clarifications suggested below.

My concern, which is something the working group probably already discussed, is
about the complexity and usefulness of the idea.

The goal of draft is:

“

   The core of this solution is the ability for an operator to specify

   on a per route reflector basis or per peer/update group basis or per

   peer basis the virtual IGP location placement of the route reflector.

   This enables having a given group of clients receive routes with

   optimal distance to the next hops from the position of the configured

   virtual IGP location.  This also provides for freedom of route

   reflector location and allows transient or permanent migration of

   such network control plane function to optimal location.”

But I understand that there is a number of workarounds and that different paths
are already used for redundancy reasons, hence my questions is: is it worth
defining a new solution? Is the usage of the actual mechanisms
 so disoptimized to require these changes? How many possible paths are there
 between the client and the AS border node?



-



Abstract

“

   This document proposes a solution for BGP route reflectors to allow

   them to choose the best path their clients would have chosen under

   the same conditions, without requiring further state or any new

   features to be placed on the clients”

This is really hard to read. Maybe it could be improved stating what is the
problem and what the solution is. You could copy a couple of sentences from
section 1.1. which is much clear.



-



Introduction:



“ In some situations, this method suffers from non-optimal path selection”.
Which path? The one used to forward the packets? The one used to redistribute
the route? Or?

---

In a number of occurrences acronyms are not explained at first usage, e.g. POP,
L3VPN, 6PE…

---



Another general comment: I like the rich intro full of details on the problem
statement, the existing solutions and the proposed one. However I’m struggling
to understand how an implementation could be declared to be
 compliant to this ID. The only thing I see is “the implementation MUST NOT
 prevent reflecting more than one path” and an analog requirement which is “the
 route reflector MUST reflect N optimal paths”. I would have expected this to
 be an amendment to the existing RFC that states that a single path can be
 reflected.



---