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

Job Snijders <job@instituut.net> Tue, 23 July 2019 20:59 UTC

Return-Path: <job@instituut.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37112039B for <sidrops@ietfa.amsl.com>; Tue, 23 Jul 2019 13:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg5kOtEJM6kE for <sidrops@ietfa.amsl.com>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DC7120159 for <sidrops@ietf.org>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
Received: by mail-oi1-x22a.google.com with SMTP id a127so33373064oii.2 for <sidrops@ietf.org>; Tue, 23 Jul 2019 13:59:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; 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; d=1e100.net; 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: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net>
In-Reply-To: <77600356-557E-43F6-82AB-5AFFB830B984@juniper.net>
From: Job Snijders <job@instituut.net>
Date: Tue, 23 Jul 2019 20:59:41 +0000
Message-ID: <CACWOCC-qhjA1L6Xoi2J4cvW=Ksor3wENXc8wgmwQqHCYKZ6wVw@mail.gmail.com>
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qHI6tdoUdYMcb7In4b19Kj-0aj4>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-signal-02
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=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,

Job

On Tue, Jul 23, 2019 at 8:48 PM John Scudder
<jgs=40juniper.net@dmarc.ietf.org> 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
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops