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

Jeffrey Haas <> Wed, 24 July 2019 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55BB31201AF for <>; Wed, 24 Jul 2019 08:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3ujePkwAWW0f for <>; Wed, 24 Jul 2019 08:26:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A97FB12034C for <>; Wed, 24 Jul 2019 08:26:37 -0700 (PDT)
Received: by (Postfix, from userid 1001) id C836E1E2F4; Wed, 24 Jul 2019 11:28:25 -0400 (EDT)
Date: Wed, 24 Jul 2019 11:28:25 -0400
From: Jeffrey Haas <>
To: John Scudder <>
Cc: "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 15:26:39 -0000

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