nanog mailing list archives

Re: RPKI implementation


From: Randy Bush <randy () psg com>
Date: Mon, 20 Jun 2016 10:59:45 +0200

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.

6810

   A client MAY drop the data from a particular cache when it is fully
   in sync with one or more other caches.

   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.

   If a client loses connectivity to a cache it is using, or otherwise
   decides to switch to a new cache, it SHOULD retain the data from the
   previous cache until it has a full set of data from one or more other
   caches.  Note that this may already be true at the point of
   connection loss if the client has connections to more than one cache.


Current thread: