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

[Robert Raszuk <[e-mail]>]

Job,

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

It would be helpful to hear from vendors how propagating to BGP an IGP
metric in the scenario
of N-level of recursion is easy or hard for them.

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

Ok in such a case I don't see any problem of addressing the ambiguity with
the below sentence
added to section 4.1:

Current text:

   "In this document we refer to optimal as the decision made during best
   path selection at the IGP metric to BGP next hop comparison step."


New text:


   "In this document we refer to optimal as the decision made during best
   path selection at the IGP metric to BGP next hop comparison step.


   In the scenario of BGP route's next hop resolving via N level recursion
   the metric used for given path's comparison (provided implementation
   supports it) should be equal to IGP metric of the final IGP route the
   N level recursion resolves via. Similarly next hop reachability
validation
   should be based on the state of such IGP route."

Would WG and yourself be fine with this change ?

The only problem is what to do if implementation can not propagate such
metric .. should the N-level recursive path be less preferred and assumed
having max metric in such cases ?

Thx,
R.


On Mon, Oct 9, 2017 at 5:20 PM, Job Snijders <[e-mail]> wrote:

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