[RTG-DIR] Rtgdir early review of draft-ietf-idr-bgp-optimal-route-reflection-21

[Daniele Ceccarelli via Datatracker <[e-mail]>]

Reviewer: Daniele Ceccarelli
Review result: Ready

The draft has been significantly improved since my previous review (v11).
Since the draft progressed till v21 i assume the working group found an
agreement on the usefulness of the idea. Please see my previous comment:

"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?"

I see that appendix A has been added with alternative solutions, very good.

I only found minor comment and nits.
- Astract: "to choose the best path for their clients standpoint" i guess this
should be "From their clients standpoint" - Abstract: "multiple type - multiple
types" - Section 3: there are some issues with bullet items - Section 3: "The
first change is related to the IGP cost to the BGP Next Hop, which is done in
the step e) in the BGP decision process" where is step e) defined? maybe a
missing reference? ...further reading the document i find a description of step
e) in section 3.1. Maybe just saying "as described in section 3.1 " would be
enugh. - Section 3.1. Since step e) is modified probably the draft should
update RFC 4271?

Overall i like the way that the abstract and the introduction have been
updated, with the former introducing the solution and the latter well
explaining the problem to be solved.