IETF Logo Mail Archive

Re: [Sidrops] trying to limit RP processing variability

Di Ma <madi@zdns.cn> Wed, 15 April 2020 13:42 UTC

Return-Path: <madi@zdns.cn>
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 D59133A07E3 for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 06:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IVfCrWg8fynh for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 06:42:31 -0700 (PDT)
Received: from smtpbguseast2.qq.com (smtpbguseast2.qq.com [54.204.34.130]) (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 518FE3A07E1 for <sidrops@ietf.org>; Wed, 15 Apr 2020 06:42:29 -0700 (PDT)
X-QQ-mid: bizesmtp17t1586958144tkunyks7
Received: from [192.168.3.24] (unknown [118.198.181.5]) by esmtp6.qq.com (ESMTP) with id ; Wed, 15 Apr 2020 21:42:22 +0800 (CST)
X-QQ-SSF: 00400000002000N0ZI80000A0000000
X-QQ-FEAT: eEBym+G8tbZVnYGU3H3FCvZ41OPZQ+vSdFx0n1f35ygfLCAcj0uDVZb3tc8YJ stlCAKPJbAyfBlx21H4hroLgfzh7LxgFI7gwD/CNdy89lwN625G0w37f9hCjg/XCI9ha69c rthiGdaAoeMBp11LJpnsimOQyrgtizfgrQtPbt2mJ7UOGVy0PzWvidfIt5FwtMRH2cCcR5q CnrqJuLp88u+AsI4J0toKJuwYp6MZnxY/fUAw90ETQi0JYCoGPVl/lDHfnQfb5bnoHXRVhF f8aXbEBFsrkQtGR+Jehx2+enDX+7zMot+LdzbD1c5TyDZpuwyLG+0f3VQZv2qZDppNMGELs oZmeRsndTjJG2DqYZcqrqutLkWAiQ==
X-QQ-GoodBg: 2
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <9688fef0-7f3f-479d-b8a0-2095ac0fe3a2@verizon.net>
Date: Wed, 15 Apr 2020 21:42:20 +0800
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E30797D-C10A-4DE9-934F-011B769F220F@zdns.cn>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net> <e3bcba98-c664-0c27-850f-137251cc314a@ripe.net> <a1c7b748-6dda-c555-0ab7-3727d34bc672@verizon.net> <1f788965-aa0e-665d-0a3e-f1196b1c39c3@ripe.net> <9688fef0-7f3f-479d-b8a0-2095ac0fe3a2@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, Robert Kisteleki <robert@ripe.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgforeign:qybgforeign5
X-QQ-Bgrelay: 1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sea3zKIYCuIwjR1vERCSj6pZGL8>
Subject: Re: [Sidrops] trying to limit RP processing variability
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: Wed, 15 Apr 2020 13:42:38 -0000

> 2020年4月15日 19:58，Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> 写道：
> 
> Robert,
>> ...
>> I agree. However, that's not the practice today. Which is why I latched
>> on to your proposal and I'm trying to highlight that we should cover this.
>> 
>> Cheers,
>> Robert
> 
> We should ask Di Ma if RPSTIR-2 still follows the design approach I cited.


Steve is right.

RPSTIR2 still follows the very design approach.  

In terms of synchronization, RPSTIR2 keeps its incumbent local version exactly the same with global repositories. 

Granted, RPSTIR2 keeps the historic versions for diagnose and analysis. 

I think we just need to keep RP in alignment with PP and then can perform some analysis and diagnose (if necessary) to ascertain errors (RFC 8211) to give warning or make use of SLURM (RFC8416) if the RP operator is confident enough that he catch the wrong data and knows how to remedy locally. 

Di

v2.23.0 | Report a Bug | By Email