IETF Logo Mail Archive

Re: [Sidrops] Publication Point -> RP synchronization in bandwidth constrained environments (note for RRDP v2)

Mikhail Puzanov <mpuzanov@ripe.net> Thu, 08 June 2023 16:09 UTC

Return-Path: <mpuzanov@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 A5518C151092 for <sidrops@ietfa.amsl.com>; Thu, 8 Jun 2023 09:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FGonV7ram3lY for <sidrops@ietfa.amsl.com>; Thu, 8 Jun 2023 09:09:12 -0700 (PDT)
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 93673C14CF12 for <sidrops@ietf.org>; Thu, 8 Jun 2023 09:09:12 -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=e3+Rh4sosvbTT7vxZ3MQMofi0Sqo/0ch40imUsWpuVs=; b=I3ws59lFFXlZYiMxb2VGRSld on/wl+GKQLAdLVZCfxDRMxhGprzqomgS2cGLfa4n85w7cYdcI4nLMo/E6xtmwVeACBUzYrWwCwbrq +9M9Iun7ooSGfSfTlALledoKL4vyUTTnokRUM3AnOpwvoKduKIqbkY4nxInveRpBKk0JR0s5YDVAQ JRsJ6KK+zVli7oBFsuMMs3jRksHAE0Yae8LvB/buDy2Bdi/834+wVB66Qa4nesvTynrXA5MCVsyJQ ds7LxadBRvmgRKbwjVEe/Onzki2CX7KPtJnmPWkjGPl3J/x808oXPq2AOGTzsIug80JpAKTuZM4P2 0H7Mo75jlQ==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:37346) by mail-mx-2.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <mpuzanov@ripe.net>) id 1q7ICE-008HAs-21; Thu, 08 Jun 2023 16:09:10 +0000
Received: from sslvpn.ripe.net ([193.0.20.230] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <mpuzanov@ripe.net>) id 1q7ICE-0000tl-1a; Thu, 08 Jun 2023 16:09:10 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
From: Mikhail Puzanov <mpuzanov@ripe.net>
In-Reply-To: <ZIHLBTZJ06/J3bCa@diehard.n-r-g.com>
Date: Thu, 08 Jun 2023 18:08:59 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6C4BC22-C01E-49D2-86E2-81B987FFBEE6@ripe.net>
References: <ZHYYt77xdtrkNV1a@snel> <955CFF67-8D19-4B38-8585-3754F3119EDF@ripe.net> <ZIHLBTZJ06/J3bCa@diehard.n-r-g.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3731.500.231)
X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e060537d0a9b0dd0d22855e5179963d9e4
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sNTYHyGfZlMnwLUU614cyqS01h4>
Subject: Re: [Sidrops] Publication Point -> RP synchronization in bandwidth constrained environments (note for RRDP v2)
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 Jun 2023 16:09:17 -0000



> On 8 Jun 2023, at 14:35, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> The inherent problem of RRDP is that when a CA is forced to issue a new
> RRDP session (or all RP lose their RRDP state for the CA) every RP system
> will grab a snapshot. So you end up with a thundering herd and I doubt a
> reduction by half is enough to make that effect go away. 

Fair enough. 

The only protection from full snapshot download on session reset would be some 
kind of content comparison, similar to what rsync does. It MAY be useful to
publish some kind of "snapshot digest”, i.e. the list of only urls and hashes 
to be used after session reset as an indication that the content didn’t change
and there’s not point to download the snapshot. How useful such a thing would 
be in practice is hard to say without trying.

We may look this way, but I’m afraid all these extensions of the protocol would 
complicate it a lot.

--
Mikhail Puzanov,
Specialist Software Engineer,
RIPE NCC

v2.23.0 | Report a Bug | By Email