Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)

Job Snijders <> Wed, 18 November 2020 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D30E3A1840; Wed, 18 Nov 2020 04:27:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KBGv_Q-2Dgoa; Wed, 18 Nov 2020 04:27:47 -0800 (PST)
Received: from ( [IPv6:2001:418:3ff:5::192:26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E12ED3A183E; Wed, 18 Nov 2020 04:27:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id EDB42EE0157; Wed, 18 Nov 2020 12:27:43 +0000 (UTC)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id 08f753d1; Wed, 18 Nov 2020 12:27:42 +0000 (UTC)
Date: Wed, 18 Nov 2020 12:27:42 +0000
From: Job Snijders <>
To: Di Ma <>
Cc: SIDROps Chairs <>, "" <>, Guyunan <>, SIDR Operations WG <>, Chris Morrow <>, Melchior Aelmans <>, Christopher Morrow <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] WG ADOPTION - draft-madi-sidrops-rush - ENDS 10/12/2020 (Oct 12th)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2020 12:27:48 -0000

On Wed, Nov 18, 2020 at 02:48:33PM +0800, Di Ma wrote:
> > Furthermore I do not believe that the SLURM format is optimal to
> > distribute Validated RPKI cache data. It is inefficient from a size
> > perspective. The SLURM format makes a lot of sense for describing
> > 'Local RPKI exceptions', but the datastructure seems less suitable
> > as the RPKI grows in size.
> I don’t agree in terms of SIZE.

Hmmm, when analyzing the SIZE difference:

    $ du -sh slurm.json rpki-client.json
    16.3M   rpki-client.json
    20.3M   slurm.json

The size difference can be explained because the non-standard format
uses 'maxLength' as key, and SLURM uses 'maxPrefixLength' (which is more

Furthermore, the SLURM format does not have a "ta" (Trust Anchor) key,
so the SLURM format offers *less* detail than the non-standard format.
The SLURM format also does not have the "metadata" key, which contains
valuable metadata about the set of VRPs the JSON object describes.

> The beauty of SLURM file is that it naturally supports incremental
> update.

As far as I can see SLURM does not 'naturally support incremental
updates'. Can you please elaborate on this 'natural' property?

Reading the SLURM RFC it has a section on "atomicity", making it clear
that a partial SLURM file is problematic, and further more it specifies
how to deal with multiple SLURM files, which is not the same as
'naturally supporting incremental updates'.

> > Many operators *already today* are using different formats, so why
> > not either look to standardize the format that actually is in use in
> > the wild, or optimize towards something that is better than what is
> > already used in the wild?
> I am pleased to know those operators have *already today* used some
> other formats that works for their networking condition.
> If they want a standardized format, it is fine and good.  But this
> won’t necessarily stop RUSH from being a WG item.  

I would encourage you to not ignore feedback from operators such as
myself. It seems the authors are ignoring the lessons learned from
existing solutions.

Operators (like myself) have experience with large-scale Route Origin
Validation designs where RPKI Cache Validators and RTR servers are
separate network elements. This experience must not be ignored.

There are 5 (!!!!) validator implementations which support a common
(not-yet-standardized) format used in many real-world deployments. From
this tangible experience we know some of the good and bad sides of the
particular format.

SIDROPS can choose between 3 options: do nothing; or standardize the
existing commonly used format; or improve the existing deployed format.

Investing working group time in a *WORSE* format is not an option.

Kind regards,