IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-rov-no-rr-01.txt

Ties de Kock <tdekock@ripe.net> Wed, 11 May 2022 06:29 UTC

Return-Path: <tdekock@ripe.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 3698DC15E6F5 for <sidrops@ietfa.amsl.com>; Tue, 10 May 2022 23:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level:
X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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=ripe.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZuIPWj8mYvo for <sidrops@ietfa.amsl.com>; Tue, 10 May 2022 23:29:09 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FE5C15E6EE for <sidrops@ietf.org>; Tue, 10 May 2022 23:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=CFtrH6Z8AGJE6nsm8QKNrMSfjZFua3qTDce4n6m7EHM=; b=eP/l1yjsZ33bXp8nJ8sadFb9 NfQWGzEicc6TCrGIDaZqIZrrMk8yzrjfkM6DvT0yt8MEctbzqsZB/XM+E8uE1nHy1kn74HV0CWBcc CKKpYruRjc1nZiswGwDLM6Tg4SfnZSuG3dfBuUctvRo+nkAoB1y6Ir+DOxLwIJS3HDCC2EKPgQ1SF 5eZeIBpZTKNHFgAU41CXZX4zskwGCG+a5HZGsc6cg+yVOxTSAPhi30pwl9sus0y5WPDng3eKj1FZU Xt1yA+DAXeEdK15nGUF9R2Tl4eTI3lj1j5SuJ3zQAMpJb615Jeu0uZGKOiqMOau+Z1q303Put1mbp jXp00L8o5w==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:53546) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1nofqM-000Ccv-CZ; Wed, 11 May 2022 08:29:06 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <tdekock@ripe.net>) id 1nofqM-0008Ja-8A; Wed, 11 May 2022 06:29:06 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <m2fslmnwqd.wl-randy@psg.com>
Date: Wed, 11 May 2022 08:29:05 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <B2602263-BBC1-4ED0-BD35-F9E5A90B74EF@ripe.net>
References: <165187444339.21170.13445821749382495729@ietfa.amsl.com> <m2fslmnwqd.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1c0b6b3bfdcb0ac56dcb19452b285959c
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ghCoK5qS5Ybn8LcOr91JcI31ows>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rov-no-rr-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 11 May 2022 06:29:14 -0000

Hi Randy,

> On 7 May 2022, at 00:04, Randy Bush <randy@psg.com> wrote:
> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rov-no-rr-01
> 
> the bad news is
> 
>   If new RPKI data arrive which invalidate the best path, and the
>   router did not keep all alternatives, then it MUST issue a route
>   refresh so those alternatives may be evaluated for best path.

Just to make sure this is the intended behaviour: When new RPKI data arrives
that transitions a 'better' route that was invalid to unknown or valid, the
router will stick to the old preferred route.

It only switches when the best path is invalidated. Do we want to be explicit
about this downside?

Can we simulate or estimate the impact of the specification in section 4?

Kind regards,
Ties

> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email