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

[Robert Raszuk <[e-mail]>]

Hi Job,

In general I agree that implementations should be consistent in their
behaviour, but the reality is that they are now. But let's focus on your
observation for a moment ... With that few questions come up:

1. Are you using the same implementation on both client and RR with ORR ?

2. Can you send output from both ORR context and client for:

show (ip) route 192.0.2.0 det
show (ip) route 198.51.100.101 det
show (ip) route 203.0.113.203 det

The problem usually is related here not to BGP implementation but to RIB.
Not all RIBs reference a metric of N-level recursive route to the child.

When BGP registers its next hop with RIB for state/metric tracking
(assuming that implementation even does that rathere then a single call to
RIB) the metric it get's is the one attached to the specific next hop which
is being queried.

Bottom line is that mandating suggested text to the current spec may very
likely result in number of implementations to become non-compliant and what
is worse the proper fix may require in some cases complete RIB redesign
which is far from BGP and IDR area.

For your valid case I would suggest perhaps to solve it via
draft-ietf-idr-bgp-nh-cost-02.

If you find vendors buying into your case we will be more then happy to
update the NH cost draft and progress it.

Kind regards,
Robert.



On Mon, Oct 9, 2017 at 10:11 AM, Job Snijders <[e-mail]> wrote:

> 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
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>