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

What if after say N levels of recursion it ends up on IGP leaf with metric
X to it from the logical placement perspective ? Do you pass this metric X
to BGP to be used in NH metric comparison among other paths (which may be
also N level recursive) ?

Ending up on SPF root in the logical RR placement would be the remote
client node so 0 is OK, but the crux of the question here is really above.

Thx,
R.

On Mon, Oct 9, 2017 at 11:11 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> We have been assuming that the metric of a BGP hop is 0. Accordingly:
>
> If it fails to resolve during the recursion, then it is unreachable.
>
> If the recursion ends at the SPF root, without touching an IGP reachable
> NH, then the metric is 0.
>
>
>
> Thanks,
>
> Jakob
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, October 9, 2017 2:03 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* Adam Chappell <adam.chappell@gmail.com>; idr wg <idr@ietf.org>;
> ytti@ntt.net
>
> *Subject:* Re: [Idr] WGLC for draft-ietf-idr-bgp-optimal-
> route-reflection-14
>
>
>
> 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) <jheitz@cisco.com>
> 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:idr-bounces@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Monday, October 9, 2017 12:25 PM
> *To:* Adam Chappell <adam.chappell@gmail.com>
> *Cc:* idr wg <idr@ietf.org>; ytti@ntt.net
> *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 <adam.chappell@gmail.com>
> 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 <robert@raszuk.net> 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 <job@ntt.net> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
>
> --
>
>
> -- Adam.
>
>
>
>
>