Re: RPKI implementation

[Randy Bush]

> 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.

Re: RPKI implementation

[Mark Tinka]

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.

Re: RPKI implementation

[Randy Bush]

>> i am aware of that.  my point was that cache purge default might
>> better be set to cache refresh interval than 60 secs.
> 
> I would agree with (and in fact, prefer) this protocol.

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.

randy

Re: RPKI implementation

[Mark Tinka]

On 16/Jun/16 16:38, Randy Bush wrote:

> i am aware of that.  my point was that cache purge default might better
> be set to cache refresh interval than 60 secs.

I would agree with (and in fact, prefer) this protocol.

Mark.

Re: RPKI implementation

[Randy Bush]

> That is also configurable.
>>> When a cache loses connectivity, the entries from that cache
>>> are purged after a time interval. Default is 60 seconds
>> why not the poll interval for that cache server?

i am aware of that.  my point was that cache purge default might better
be set to cache refresh interval than 60 secs.

randy

Re: RPKI implementation

[Jakob Heitz (jheitz)]

That is also configurable.

Thanks,
Jakob.


On Jun 16, 2016, at 4:39 AM, Randy Bush  wrote:

>> When a cache loses connectivity, the entries from that cache
>> are purged after a time interval. Default is 60 seconds
> 
> why not the poll interval for that cache server?
> 
> randy

Re: RPKI implementation

[Randy Bush]

> When a cache loses connectivity, the entries from that cache
> are purged after a time interval. Default is 60 seconds

why not the poll interval for that cache server?

randy

RPKI implementation

[Jakob Heitz (jheitz)]

During the RPKI presentation there was a question about
resilience of the router if the RPKI cache loses connectivity.
The IOS-XR implementation allows multiple caches to be configured.
When a cache loses connectivity, the entries from that cache
are purged after a time interval. Default is 60 seconds and it is configurable.
A lookup of a prefix that is not loaded will return not-found.
5 seconds after the latest RPKI database update,
a refresh request is sent to each neighbor, provided that the neighbor either:
- dropped any received route due to a policy that contains validation-state, or
- received a route, the validation state of which changed.
If soft reconfiguration inbound is configured, then the refresh is avoided,
because the received paths are stored.

Thanks,
Jakob.