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

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 05 November 2019 15:21 UTC

Return-Path: <tim@nlnetlabs.nl>
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 4AD1E1200D7 for <sidrops@ietfa.amsl.com>; Tue, 5 Nov 2019 07:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uErd25QrgU1e for <sidrops@ietfa.amsl.com>; Tue, 5 Nov 2019 07:21:12 -0800 (PST)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6F9120090 for <sidrops@ietf.org>; Tue, 5 Nov 2019 07:21:11 -0800 (PST)
Received: from [IPv6:2a04:b904::8e] (unknown [IPv6:2a04:b904::8e]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 96CA6261F7; Tue, 5 Nov 2019 13:53:14 +0100 (CET)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1572958394; bh=V6j0xnXVtztJY4pbDglm4YMo/AL5ks7ydQslHsrhGKU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=AqdgzQj1F/6jcCvW3mVFPg0A08qLbPAbBB1SfSUa64Zxaz9SzB4U5PSdU4aVzx7Sh +wK0kRSTiGWe5KQ6smzRHDIb5Ic1X0+Y8W20gFvQxEdybMdePrxdsFARPuoK4x7gky odAGMKIoUpw5cMlouL9/GS4tLjQSQ/04SgahUTUc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <m21run4gup.wl-randy@psg.com>
Date: Tue, 5 Nov 2019 13:53:14 +0100
Cc: Keyur Patel <keyur@arrcus.com>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <135BB020-74E9-44DE-9035-C9A669C4B8F9@nlnetlabs.nl>
References: <BF54FF5C-64D5-41BE-976C-A816BF53D3FD@nlnetlabs.nl> <0E85EC25-8EDC-4DFB-9A24-A311989809FD@arrcus.com> <21606311-A549-4537-938C-0FBFBEE71E10@nlnetlabs.nl> <m21run4gup.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/oLQJ4cNfBHBoZaiPhLJFmXZoAcA>
Subject: Re: [Sidrops] deploy deprecate rsync, was: IETF106 -- Singapore -- Call for Agenda Items
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 05 Nov 2019 15:21:13 -0000

Hi Randy,


> On 4 Nov 2019, at 19:49, Randy Bush <randy@psg.com> 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