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

[Job Snijders <[e-mail]>]

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
bytes).

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,

Job