Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02

[Jeffrey Haas <[e-mail]>]

On Tue, Jul 23, 2019 at 08:48:01PM +0000, John Scudder wrote:
> Things I would have said at the mic had time allowed:
> 
> 1. For what it’s worth, RFC 4271 section 9.1 says you aren’t allowed to have this feature:
> 
>    The function that calculates the degree of preference for a given
>    route SHALL NOT use any of the following as its inputs: the existence
>    of other routes, the non-existence of other routes, or the path
>    attributes of other routes.  Route selection then consists of the
>    individual application of the degree of preference function to each
>    feasible route, followed by the choice of the one with the highest
>    degree of preference.
> 
> As I understand section 5 of the draft (as informed by Randy’s description), it is exactly mandating that we use the path attributes of other routes for the computation of the degree of preference.
> 
> 2. Assuming we overcome that problem, there appears to be a stability and/or freshness issue:

[Example elided]

FWIW, I'd observe that the given use case in the draft is a route reflector
or other BGP speaker.

Since a BGP speaker normally would only send a route to a given BGP speaker
based on having performed route selection, the sender of the route to be
proxy validated should expect to not receive the route in many cases since
it's not the selected best path.

John's example shows a case where we might end up in some undesirable cases.

The desire in this draft is to leverage existing BGP plumbing.  It's an
awkward fit as currently discussed. Thus I'm with John in not being in favor
of adoption at this time.

-- Jeff