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

[Job Snijders <[e-mail]>]

On Mon, Oct 09, 2017 at 04:25:27PM +0200, Robert Raszuk wrote:
> 1. Are you using the same implementation on both client and RR with
> ORR ?

Sometimes.

> 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.

No, this is an optimal route reflection specific challenge. A vendor
read the document, and didn't consider the case where a BGP next-hop
may recurse through another BGP route to an IGP route. This is a simple
oversight that probably would not have happened if the document
specified how to consider route recursion from via one or more
protocols.

> 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.

I think you are overestimating the impact of the proposed change.

> 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.

I disagree, draft-ietf-idr-bgp-optimal-route-reflection is the right
place for this.

The specific vendor I was referring to told us that they'll change their
behaviour: they'll fully recurse the BGP routes at route reflector,
before chosing which route to reflect. The fact that they released
software without this capacity, implies draft has ambiguity which causes
operational inconsistency in best path algortihm (with possibility for
blackholing).

Kind regards,

Job