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

[Job Snijders <[e-mail]>]

On Mon, Oct 09, 2017 at 05:56:44PM +0200, Robert Raszuk wrote:
> > 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.

I think the number of BGP implementations that can't do BGP to BGP to
IGP recursion is extremely small, it'll be mostly the implementations
that don't support the IGP or already operate without RIB.

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

I think some wordsmithing may be needed to improve the readability. The
word 'recursion' or 'recursive lookup' should probably be used.

NEW:

    """
    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 where a path's BGP next-hop can only be resolved
    through multi-level recursion, the metric used for a given path's
    comparison SHOULD be equal to the IGP metric of the final IGP route
    the recursive lookup resulted in. Similarly, next-hop reachability
    validation should be based on the state of such IGP route.
    """

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

Good question, 'assuming max metric' will at least prevent certain
blackholes compared to 'not announcing'. Vendors may want to chip in
here on what their implementation does. The document will be better off
if we highlight this problem and make a recommendation (such as 'treat
as less preferred').

Kind regards,

Job