Re: [Sidrops] deploy deprecate rsync, was: IETF106 -- Singapore -- Call for Agenda Items

[Tim Bruijnzeels <[e-mail]>]

Hi Randy,


> On 4 Nov 2019, at 19:49, Randy Bush <[e-mail]> wrote:
> 
> tim,
> 
> great to get the draft out there.  

Before responding to your points below, I want to highlight another aspect of this document:

I propose that rsync URIs continued to be used as identifiers, even if there may no longer be an rsync service. Identifiers will still be useful, and introducing e.g. URNs for this would introduce breaking changes, and this would make it much, much harder to progress.


> wish it was more specific about how
> this is operationally accomplished.  e.g. from the discussion i was
> trying to have with you:

Indeed, for the moment document just focusses on an end goal where neither publishers, nor RPs need to implement rsync.


The following time table can indeed work:
> 0 - publishers publish rcynic and some rrdp.  rps use rcynic and some
>    use rrdp
> 
> 1 - all publishers offer both.
> 
> 2 - then you can ask all rps to move to rrdp and prefer it
> 
> 3 - you can see, at the publishers, when no rcynic requests come
> 
> 4 - you can turn off rcynic at the publishers
> 
> 5 - you can remove rcynic from the rps

And after having reached out to some RIRs I have good hope that this is not too far off. Still, when we spoke I proposed a different timeline, which assumed (perhaps wrongly) that RPs would update their code, before publishers:

0 - publishers publish rcynic and some rrdp.  rps use rcynic and some
   use rrdp

1 - all RPs support RRDP and prefer it

2 - you can see, at the publishers, when no rcynic requests come

3 - you can turn off rcynic at the publishers

4 - we ask all publishers to support RRDP

5 - RPs can drop support for rsync


I don't have enough information to know which comes first. Therefore the document currently just says that:
- RPs can drop support for rsync when all publishers support RRDP,
- publishers can drop support for rsync when (almost) all RPs support RRDP

The latter is a bit of an issue, because even if all recent RPs support RRDP, there will probably be some old versions deployed. There comes a point where you may need to leave some behind. Within reason of course, and after measuring. I don't think we can agree on a magic number. But some kind of flag day seems unavoidable.

I am all for discussing this on the list and during the session, but for now I did not feel comfortable proposing one way in the doc. Also, we probably would want to remove this before last-call (assuming adoption of course..).

Tim





> 
> 
> randy