Re: [Sidrops] RRDP / RSYNC / Other?

[Job Snijders <[e-mail]>]

Dear all,

On Thu, Jan 11, 2024 at 10:52:55PM -0500, Christopher Morrow wrote:
> The 'prefer rrdp' draft has been sitting(expired)  for a while, I had
> thought when the document started life there was a set of good reasons
> for this plan. I think I still want to prefer 'not rsync' on my RP
> deployment :)

"not rsync" - in practise - would've meant that for multiple months in
2023, your RP would not have had access to AFRINIC ROAs.

> I believe that a longer term goal for rrdp (and the draft in question)
> was to eventually decommission/deprecate the RSYNC code paths, as
> well.

Well, that is not my goal. Before we even consider deprecation of rsync,
there first needs to be a viable alternative to both RSYNC and RRDP v1.

As it stands - RRDP has numerous inefficiencies, implementation
inconsistencies, curious pitfalls, unforeseen operational failure modes,
and performs extremely poor in low bandwidth situations. But of course,
rsync is not without its own issues and complications. Fortunately, not
a lot of the failure modes are shared between the transport protocols,
meaning that one is a good backup for the other.

I think some people in this working group underappreciate the benefits
of rsync as a (backup) transport, especially in the face of instability
in the RRDP transport. As long as people are stuck in just mindlessly
repeating "rsync bad" and refuse to see and articulate the benefits that
rsync offers, it'll be hard to copy those benefits over to a next gen
transport protocol.

> In light of the original reasonings for RRDP development:
>   * standard(ized) transport protocol (http)
>   * scalability and cacheability of the content
>   * easier to inspect/debug service(s)
>   (there may be others,  don't think right now its important that there are)

I agree HTTP is a standardized protocol and I hope ultimately something
HTTP-based is where we'll end up. But, the other arguments can be
challenged: RRDP 'scales so well' that we've seen RPs become an
unrecoverable denial-of-service against the publication point. In
practise rsync is easier to debug and inspect with out-of-the-box
tooling, whereas RRDP requires a quite specialized knowledge and tooling
to meaningfully debug.

> and the original arguments against RSYNC as the protocol for long term use:
>   * how could this possibly scale!
>   * i can ship random bits  to all RPs and they can't NOT accept them
>   * wow is this a bear to deal with in a programmatic manner!
>   (there may be others, not important right now what they are)
> 
> Is it time that we fresh-slate thought about this problem?
> I believe we CAN swap in 'anything' that has a URL type naming/pointing form
>   (perhaps we would need to define new url protocols, but...)
> I think if we had a solid option, with running code we could talk
> about removing rsync, preferring rrdp and testing the 'new thing'...
> or some form of that ordering.

When you actually remove rsync, RRDP no longer becomes a matter of
'preference'. :-)

> Should we take up a discussion and work to investigate a RRDP
> replacement?

The timing is not optimal from my perspective, I don't mind the status
quo. I think we should first finish:

* ASPA signed object: draft-ietf-sidrops-aspa-profile
* ASPA-based BGP message verification: draft-ietf-sidrops-aspa-verification
* ASPA RTR: draft-ietf-sidrops-8210bis
* draft-ietf-sidrops-signed-tal (has multiple implementations, authors
  requested WGLC multiple times now...)
* draft-ietf-sidrops-cms-signing-time
* draft-ietf-sidrops-rpki-prefixlist
* And there also is a recent interest to revisit the validation
  algorithm, this will all take up a fair chunk of working group
  bandwidth.

In short - deprecating rsync before having a viable alternative to RRDP
v1 is horse behind cart. A deprecation of rsync won't solve immediate
operational issues, but instead will add problems. The community now
also is aware of various optimizations that can be done to make
RRDP-to-RSYNC switchovers far less resource intensive, so scalability
concerns are not as strong as they once were.

Kind regards,

Job