IETF Logo Mail Archive

Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024

Ties de Kock <tdekock@ripe.net> Thu, 08 February 2024 08:04 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 51001C14F6F3 for <sidrops@ietfa.amsl.com>; Thu, 8 Feb 2024 00:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 p-GvdAAZhNtV for <sidrops@ietfa.amsl.com>; Thu, 8 Feb 2024 00:04:00 -0800 (PST)
Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3356CC14F689 for <sidrops@ietf.org>; Thu, 8 Feb 2024 00:04:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Cc:Date:Subject:Mime-Version:Content-Type:Message-Id:From ; bh=UJJkrHJw5bz/dVEJkkqtZGHQ2t+o26wDcKb1NPXRHls=; b=gEBZGZgE8yrBR3D6oHDxjYm9 mjTLs3E0JNdVgm80vyTuTlAmn0kSFFZtkjRL+JJ/RbJ17ysV7rL6G8Wg67fq+rf6Vsc+8BvSbM00k vcM3MsdXTgiuwsNVY4pu+ZSTt8RLngb3PHMJdFV3iLhf5T85ptjUNxFSrOzDP9Uk6N/bEplFrnVlI jbQ36qTuk9wRxnlvFdOpVvhWd38LdyR1IFqI5XwlrIgcqFMQGgLMVf7Da0OVvyQlwA9+5xURAL2/H nDI9O9veBPdzQMnvVo/Vb3neYZCiEaEY5FKS6/O0cn4o7DBOph6HI7xCPKIjTQT91YtFaFga4JPA3 /b4MtRSAvA==;
Received: from imap-01.ripe.net ([2001:67c:2e8:23::c100:170e]:51178) by mail-mx-2.ripe.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <tdekock@ripe.net>) id 1rXzO1-00BTff-23; Thu, 08 Feb 2024 08:03:57 +0000
Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by imap-01.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from <tdekock@ripe.net>) id 1rXzNl-00DB25-0p; Thu, 08 Feb 2024 08:03:57 +0000
From: Ties de Kock <tdekock@ripe.net>
Message-Id: <D8D0D371-1547-4E2B-A49E-CAD62DFD4329@ripe.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9A25099A-CA7B-42FC-B6B6-16E969394E37"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Thu, 08 Feb 2024 09:03:29 +0100
In-Reply-To: <CACC_My9V8MPQFwkW01Y6B=T-RO5dqb6C0Z21oyTXPVzU9w+ZoQ@mail.gmail.com>
Cc: IETF SIDRops <sidrops@ietf.org>
To: Lukas Tribus <lukas@ltri.eu>
References: <87h6j1kug1.wl-morrowc@ops-netman.net> <B60D7B39-FA81-45AF-BCBD-2784F91B43C3@vigilsec.com> <ZcFNNfrkMFxKf5hN@snel> <BBE2320C-4525-4713-B4AF-3F00ECD4228A@ripe.net> <ZcIuI7lS1OtOW_xT@snel> <EFFA95AA-F07D-490B-BEC3-0446ED2D3AA2@ripe.net> <ZcJmeFCmU9Txsk7M@snel> <ZcJulgLqKapjnvYn@snel> <CACC_My9V8MPQFwkW01Y6B=T-RO5dqb6C0Z21oyTXPVzU9w+ZoQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.400.31)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1bbe43b0c713e92c531bbdbff15574c41
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/4cCuvd52wBa5izY3uKQdMdmiVNM>
Subject: Re: [Sidrops] [WG ADOPTION] Adoption call: draft-timbru-sidrops-publication-server-bcp - ENDS 02/08/2024
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 08 Feb 2024 08:04:05 -0000

Hi Lukas,

> On 7 Feb 2024, at 18:01, Lukas Tribus <lukas@ltri.eu> wrote:
> 
> On Tue, 6 Feb 2024 at 18:38, Job Snijders
> <job=40fastly.com@dmarc.ietf.org <mailto:job=40fastly.com@dmarc.ietf.org>> wrote:
>> 
>> Dear all,
>> 
>> On the topic of the publication best practises, it might be good to
>> strongly recommend that RRDP notification file, delta files, and
>> snapshot file all be hosted on the same FQDN. But, AFAIK, the RRDP
>> specification doesn't actually require this.
>> 
>> This 'same origin' check was added back in 2021 to rpki-client to guard
>> against notification files pointing to giant files on open source
>> mirrors or towards other people's (large) RRDP snapshots.
>> 
>> Since 2021, the global RPKI publication ecosystem appears to naturally
>> comply with this informal expectation, as in, the check doesn't appear
>> to cause friction.
> 
> Maybe only slightly related, but any thoughts on using multiple CDN's ?

Job Snijders' message has a good explanation of the technical details. I can add some
operational context for our repository. 

The RIPE NCC uses multiple CDNs behind a CNAME with a low TTL that we change
weekly. The main advantage we see in this that we can shift _all_ the traffic
to one target destination when we want (e.g. we observe or are made aware of
issues).

At our traffic levels (and maybe in general) the billing is volume-based - there
is no incentive to balance traffic at a finer granularity.

Kind regards,
Ties

v2.27.6 | Report a Bug | By Email | System Status