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

Job Snijders <> Tue, 23 July 2019 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F37112039B for <>; Tue, 23 Jul 2019 13:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fg5kOtEJM6kE for <>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87DC7120159 for <>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
Received: by with SMTP id a127so33373064oii.2 for <>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pGCfyedOs6gHqH+lm5jjigG9UYvOEYO3dW+/XDYlUYI=; b=csYrgHn+k0D+D0kIEako9PsgkGCf55twyK2PfJHF/mGb2/bJVu9Shk5EbVTcx5hMkt n1XpXPYqXigkVWknXVrwUpQQFkqZTtZU1z+krjW5xspXaGWpGh8CXmdPFoywT1YeOP3U AkPszX2dpY2bN8hmKHiMgLuAKoAmnvQZi4TOj/xA7pRxaeG8XK8NkeCCcjXIwRbW9Qo8 cTtstoElc8MMpvpNZqyPn7SHHkKdyaESG7Vaj9mOb/dDeWxqKsyv1jS2ojNgkUkxy7UX UesMPWkYw6n+7Hd98Xb3JUnwWR2sUiMfKmAG6G6Z3oBuY0FE0lGGKozZAgihfwu/cCSU R8hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pGCfyedOs6gHqH+lm5jjigG9UYvOEYO3dW+/XDYlUYI=; b=taalwg8XW2r1nT515IrqGO6ScdA7HtSmkA8e8DKS3qV7lnZ1162h25vKyARrCE5cxO ZNtL+bIaT7buw1QOR4/aKF/D/bY73pa0q028rOY757ysehGPFgoHgKVwyfrHWgoDHnM/ OjdX68JMh3dTu0cEX1dzEwBDdJZkcFvn+RV0jvH/SOv81UFt9hdbFwNa+Ved0y3ut+KA 2SOwFvy2atgijsbmcUQBVToOcU1UqRsdEG1VHahu2OvmCtVMphTezt3SgyjotykFCDBj kLtcm2vLVt6p9buW501n7c8svwFTkvUoUqmJIjay+kl+agcVNErLlfyDWUixGvJqGetS d/8w==
X-Gm-Message-State: APjAAAXNd4gBEpD5bd3xWu/vZybmPpxDVMSotyTJGNwkZqdFPIfNyZ5z 88sW5bTZjAGEp7674q6JqSSgdcE9/M4wwrvQEes=
X-Google-Smtp-Source: APXvYqzvmnEUpTxnaN49l3GhUCFommwIwd45ccrfUIJJzpP+aRXHvvDRjcJSUWlVomXWPn4yQV6T2Sm95fcbqE1bt7Y=
X-Received: by 2002:aca:dc86:: with SMTP id t128mr39420097oig.130.1563915594553; Tue, 23 Jul 2019 13:59:54 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Job Snijders <>
Date: Tue, 23 Jul 2019 20:59:41 +0000
Message-ID: <>
To: John Scudder <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 23 Jul 2019 20:59:57 -0000

I have questions about this draft as well:

Why not tunnel VRPs inside BGP in a new AFI to populate the origin
validation cache on the edges? I think the BGP protocol has sufficient
hooks to model the RTR protocol fairly closely.

Or perhaps I don't understand the appeal of this mechanism. Why not
use RTR? Or if there is no room on the edge router for the memory a
VRP cache? If there is no room, can it even do Internet BGP?

Kind regards,


On Tue, Jul 23, 2019 at 8:48 PM 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:
> - RR client C advertises route A to RR
> - RR checks A, decides it is invalid
> - RR advertises A, marked invalid, back to C. Call this A’.
> - C obeys section 5 and withdraws A from everyone (including RR)
> - Following the normal operation of BGP, RR withdraws A' from everyone (including C)
> - Now A’ is not in C’s Adj-RIB-In, but A is. I believe what Keyur said on the mic was that C is supposed to have persistently marked A as invalid in the earlier step, patching the obvious stability problem.
> - Now suppose the content of the RPKI changes such that A is now valid.
> … how does A ever find this out and un-suppress A? As far as I can tell, the answer is, “it doesn’t”. RR never sees a re-announcement of A, so it can’t re-validate and announce it to be valid. So it’s just wedged.
> 3. Finally, someone commented at the mic that the work to turn validation on at C is less than the work to debug, implement, and deploy this proposal. I agree.
> Given the above, I’m not in favor of adoption (though I’m always willing to be convinced).
> Thanks,
> —John
> _______________________________________________
> Sidrops mailing list