Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

[David Mandelberg <[e-mail]>]

On 04/01/2015 01:38 AM, Randy Bush wrote:
> why are you trying to rescue the case where a router (or cache) upgrades
> versions in the middle of a session?
>   o upgrade should be very rare
>   o reload is relatively cheap
>   o and you are generating kinky corner cases to patch it
> 
> session reset.

I wasn't trying to rescue it, I was trying to ensure a session reset.

> the bloody router (or cache) will have reloaded anyway
> and does not have the old state.

Either end can upgrade to support version 1 before the other is ready;
version 1 is only negotiated after both ends support it. I know that our
cache implementation does not lose state unless the database is manually
cleared, but I can't speak for other cache or router implementations. I
agree that the simplest way to fix this issue is to require a reset
query when a new version is negotiated, but I don't think that can be
done by relying on state being lost.

For reference, here's the text that I originally proposed:

   The cache MUST maintain a separate session for each protocol version
it supports, and a router MUST NOT attempt to reuse session information
across multiple protocol versions.

If one of those requirements is too burdensome, either of them would be
sufficient by itself to ensure that a reset query happens when the
negotiated protocol version changes.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/