[190230] in North American Network Operators' Group
Re: RPKI implementation
daemon@ATHENA.MIT.EDU (Mark Tinka)
Mon Jun 20 01:47:33 2016
X-Original-To: nanog@nanog.org
To: Randy Bush <randy@psg.com>
From: Mark Tinka <mark.tinka@seacom.mu>
Date: Mon, 20 Jun 2016 07:47:28 +0200
In-Reply-To: <m2h9cq92i0.wl%randy@psg.com>
Cc: Jakob Heitz <jheitz@cisco.com>,
North American Network Operators' Group <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On 18/Jun/16 13:10, Randy Bush wrote:
> i remembered wrongly
>
> RFC6810
>
> A client SHOULD delete the data from a cache when it has been unable
> to refresh from that cache for a configurable timer value. The
> default for that value is twice the polling period for that cache.
I suppose that is alright since, in a redundant scenario, the data from
the remaining cache that (hopefully) still has a live RTR session will
continue to be valid.
In single cache scenarios, waiting for some time after the cache has
disappeared is akin to standard BGP session keepalive protocols.
However, several vendors have implemented protocol enhancements to
immediately drop BGP sessions that have failed, rather than wait for the
Hold timer to expire. I see value in that, and perhaps it might make
sense for an RPKI implementation to support the same where it is more
important for the RPKI data to be as current as possible.
Mark.
