Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-route-reflection-14

[Job Snijders <[e-mail]>]

Dear all,

On Fri, Oct 06, 2017 at 05:30:16PM +0000, John Scudder wrote:
> (This is the first of a series of WGLCs as we work to clear backlog.
> We will stagger the WGLCs somewhat.)
> 
> A working group last call has been requested for
> draft-ietf-idr-bgp-optimal-route-reflection-14. Please reply to the
> list with your comments. As usual note we cannot advance the draft
> without participation from the group. Please get your comments in
> before October 20, 2017.

I'd like to thank the authors for their hard work on this document. ORR
is a very clever improvement for deployment scenarios with centralized
route reflection. Kudos!

I have one remark at this point, I think the document would benefit from
an "Implementation Considerations" section or at least a clarification
on route recursion.

We've come across a number of implementations where there either minute
or quite large differences in how the route reflector choose the best
path on behalf of the client. One particular implementation stood out
because the effective 'route selection behalf of the client' was
very different from what the client would've chosen itself (at least in
our topology). 

Let's consider the following: we have BGP prefix 192.0.2.0/24 with BGP
next-hop of 198.51.100.101, 198.51.100.101 recurses to IGP next-hop
203.0.113.203, which has metric value of 1000. In a scenario without
route reflection the client will observe that the IGP cost to
198.51.100.101 is 1000. Note that the 198.51.100.101 BGP next-hop is not
present in the IGP.

With Optimal Route reflection (as user) I would assume the route
reflector recurses similarly as the client would, and takes into
consideration that from the client's point-of-view the metric to
203.0.113.203 is 1000 because of the recursion from BGP next-hop to IGP
next-hop. We should not end up in a situation where the route-reflector
does not offer a path for 192.0.2.0/24 to the client if the next-hop was
not found in the IGP.

It may be good to emphasize the need to do full route recursion from the
ORR client's point-of-view. Perhaps add this somewhere:

    "If the next-hop is not found in the IGP, the route reflector MUST
    recursively lookup the next-hop until an IGP next-hop is found."

However, herein lies the crux, we can only hope that the route-reflector
and the client have a similar enough routing table in which route
recursion will give the same result. At least one vendor thought "if the
next-hop is not in the IGP we'll simply not offer that path", but I
suspect that oftentimes errs to the side of breakage and I'd prefer "a
path is better than no path".

Kind regards,

Job