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

[Robert Raszuk <[e-mail]>]

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