Re: [Sidrops] rfc8210bis further review - question 3

Job Snijders <job@fastly.com> Sat, 09 March 2024 12:36 UTC

Return-Path: <job@fastly.com>
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 D4662C14F5EF for <sidrops@ietfa.amsl.com>; Sat, 9 Mar 2024 04:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (1024-bit key) header.d=fastly.com
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 ygzWDIdQXR-r for <sidrops@ietfa.amsl.com>; Sat, 9 Mar 2024 04:36:03 -0800 (PST)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 A1BF5C14F5EA for <sidrops@ietf.org>; Sat, 9 Mar 2024 04:36:03 -0800 (PST)
Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-a458b6d9cfeso227620266b.2 for <sidrops@ietf.org>; Sat, 09 Mar 2024 04:36:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1709987761; x=1710592561; darn=ietf.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=fmf9EBSrkhQd5fcBL0JFbrwCvAQb+7Z+Q+p7fvApuRw=; b=C/sEr+29Wep20xgyyzO1EG0c1BJ78LQPE52CRTBjLEE1fqFpriq7LdwYnDuggf/e1e ANpHbeUAfQ0B1w5kpqHdJ0J09fl9HAgGZnjUQZnd48pepL5fJmPEFT4dktkcw3LsoJst tDXd5L7LPT9Ual0K6nGOAziyLpI8bvw7TSKNk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709987761; x=1710592561; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=fmf9EBSrkhQd5fcBL0JFbrwCvAQb+7Z+Q+p7fvApuRw=; b=EdRCXm3bWqepeuNF+7y6HkzSElitoCjnbRkE2uvNRXGtC+s7sakChSgyzSBcXVT517 fZ7EGD5OF1nKfu8XWzIGUoMRgkJ12XQQsm+5KgxjTvanPljS0yP47sDNt0DrdDdWtdtb 94J2wIGLRg+Uh2tdaG0Z6sYraYGryivqW4d5HOGTsujVAGCn0oV5FI2LSxaDrGNXvGnl s99UGNZ5SxdApOJspvTmv05/pEvepbNyhY0D2dZT1UpcBhh3Pj2BzqTY9hz9qvEour5W 6d5N3wYJVFp9gQO9CVtZmeod/F7pXTCvacnMv6YSibjo/9CY2GFzqjOKUE0ssIS9UhrJ FDOg==
X-Gm-Message-State: AOJu0Yz9fTHw70oqq0PFBKvN8tmEOvm7z7rbfkb/AMz5N8esAFukvq5P O6HL4bSZ0/Wh+MrlGDUiCXYaiM9G4jK6ipt26B91ptKuvPs1UZddnguWKNU0+Mq0hQJgeoEDgLF aQ6+oxWvJ4YEOmgNvaQgGqVnQ5yTxtOoOhkCSu0Tbiwa+z1WL0iMcyQ5dlmVZHIpMjLzhdQIDcd 8zDntNDH7qubwFUj/nnPZzdZMk
X-Google-Smtp-Source: AGHT+IFK1dTbYo42I5Th7VeD8zkJJhy1XNKI75cYgBYZe5gnjtmKQu0DPQsqFQYdNl81cxUBzFvc3Q==
X-Received: by 2002:a17:907:11c4:b0:a43:80e2:98dc with SMTP id va4-20020a17090711c400b00a4380e298dcmr874935ejb.32.1709987760998; Sat, 09 Mar 2024 04:36:00 -0800 (PST)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id o3-20020a1709061b0300b00a45646a9e18sm842347ejg.76.2024.03.09.04.36.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Mar 2024 04:36:00 -0800 (PST)
Date: Sat, 09 Mar 2024 13:35:58 +0100
From: Job Snijders <job@fastly.com>
To: sidrops@ietf.org
Message-ID: <ZexXrjeni3FRaZ3-@snel>
References: <ZexJxZYsgNGth_Q7@snel> <ZexN0VtykWRlmGvq@snel>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZexN0VtykWRlmGvq@snel>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QUuUjrOiu7LUjT920fpCdf48Xxk>
Subject: Re: [Sidrops] rfc8210bis further review - question 3
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: Sat, 09 Mar 2024 12:36:07 -0000

Dear all,

Question 3
==========

Section 12 "Deployment Scenarios" - I'm not sure this section serves a
purpose in an already lengthy document.

For example, what's the difference between 'small' and 'large' multiomed
end sites? The section says "complex topologies are ill-advised" and
goes on to discuss caches fetching from each other rather than directly
from the RPKI, which is a complex topology because of lack of loop
detection?

Also a bit yucky how this section starts off with "may wish to outsource
the RPKI cache to one or more of their upstream ISPs", as this is not a
practise I recognize as widely used, or would recommend based on my
experience in the field. There are a handful of instances that I know
of, none of them seem optimal: a cloud provider offers a public RTR
service, they are not 'upstream', and the service is broken in subtle
ways that are very hard to troubleshoot. Some hobbyists offer RTR
servers sometimes in context of an IXP community, and this practise too
isn't 'upstream provider'.

I recommend removing section 12 in its entirety: it lacks sufficient
detail to be very useful as a deployment guide, but contains
sufficiently confusing statements that it might get in the way of
teaching fellow operators how to run RTR services.

Kind regards,

Job