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

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<http://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<http://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<mailto: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<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<mailto:adam.chappell@gmail.com>>
Cc: idr wg <idr@ietf.org<mailto:idr@ietf.org>>; ytti@ntt.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

--

-- Adam.