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

[Robert Raszuk <[e-mail]>]

Jakob,

Let me try to describe it in a bit different way ...

Prefix 1.1.1.1/24 has 3 paths each with different next hop: NH1, NH2, NH3

NH1 is an NLRI in BGP1 and it's next hop is NNH1 (IGP metric 100).

NH2 is an NLRI in BGP2 with next hop NNH2 which is again a NLRI of BGP3 and
next hop NNNH3 (IGP metric 90)

NH3 is native IGP next hop with IGP metric 110

So when you run (regular or ORR) best path on 1.1.1.1/24 you should have
all three metrics 90, 100, 110 there to pick the best path. If next hop is
not in IGP with or without recursion such path is invalid so we should not
worry about it here.

Thx,
R.





On Mon, Oct 9, 2017 at 10:41 PM, Jakob Heitz (jheitz) <[e-mail]>
wrote:

> I don't understand the phrase " if implementation can not propagate such
> metric ".
>
>
>
> Suppose we have a BGP nexthop NH1.
>
> There are two BGP routes to NH1: BGP1 and BGP2.
>
> BGP1 has nexthop NNH1.
>
> BGP2 has nexthop NNH2.
>
> BGP1 is the BGP best path, however, NNH2 has a lower (better) metric.
>
> Using the stated algorithm would choose NNH1, whereas NNH2 is actually
> better.
>
> Networks with BGP nexthops out of reach of the IGP are susceptible to this
> issue.
>
> I'm sure this is fine in most cases, but it is good to be aware.
>
> You could add it to a "deployment considerations" section.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *Robert Raszuk
> *Sent:* Monday, October 9, 2017 12:25 PM
> *To:* Adam Chappell <[e-mail]>
> *Cc:* idr wg <[e-mail]>; [e-mail]
> *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-
> route-reflection-14
>
>
>
> Hi Adam,
>
>
>
> > where an NLRI was simply omitted because the NH wasn't comparable
>
>
>
> If I have single path to a net there is nothing to compare it with so this
> step of best path does not matter regardless if you use regular RR,
> add-paths or ORR. So none of those means that we are not sending such NLRI
> in iBGP.
>
>
>
> The way I understood Job's case it is not the "NLRI itself which was
> ommited", but one recursive path to such NLRI was not considered in the
> comparison with other paths (next hops) as metric to its recursive next hop
> was not there.
>
>
>
> Thx,
>
> R.
>
>
>
>
>
> On Mon, Oct 9, 2017 at 9:15 PM, Adam Chappell <[e-mail]>
> wrote:
>
> Perhaps resolve/recurse as far as is possible/feasible and eventually fall
> back to max metric for a comparison in absence of anything else?  Would
> certainly be principle of least astonishment in Job's case where an NLRI
> was simply omitted because the NH wasn't comparable. Optimal should be
> better, but not really any worse than classic, right?  :)
>
>
>
> I don't think the recursion needs to be mandated though, much as the
> supported IGP protocols aren't mandated. It is putting the the ORR's
> Loc-RIB and selection policy into play which is what we'd avoided.
>
>
>
>
>
>
>
>
>
> On 9 October 2017 at 17:56, Robert Raszuk <[e-mail]> wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
>
> --
>
>
> -- Adam.
>
>
>