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

[David Mandelberg <[e-mail]>]

On 2015-03-25 16:13, Borchert, Oliver wrote:
> A correction for my previous email, I mixed up session id and serial
> number.
> I think to keep it simple for version 0 - 1 switches and future 
> changes, a
> change
> Within the session id and version id should trigger a “Cache Reset” 
> by the
> cache
> And the client must resynch with the server.

If the router sends a serial query, yes I agree.

> And yes, wording in this matter might need to be added - but still it 
> also
> could
> Be an implementation issue.

After talking with you in Dallas, I agree that we should try to give 
implementors some leeway here. I still think there's an issue to address 
though. Here's the case I want to prevent:

1. Router has all the data for version 0, session X, serial Y.
2. Router upgrades to version 1, disconnects, reconnects, and sends a 
serial query with version = 1, session = X, and serial = Y.
3. Cache replies with all the changes from (1, X, Y) to (1, X, Y+1), 
instead of from (0, X, Y) to (1, X, Y+1).

As you pointed out in person, one way to avoid this is for the cache to 
give each router a different session ID and track which version is used 
by each router. Then the cache can respond in step 3 with the changes 
from (0, X, Y) to (1, X, Y+1). Another way to avoid this is the first 
part of what I originally suggested: effectively requiring the cache to 
respond with a cache reset in step 3. Or the second part of what I 
suggested: requiring the router to issue a reset query instead of a 
serial query in step 2. I'm having trouble coming up with *simple* text 
that prevents the issue while allowing any solution. If you can think of 
something, that would be great. Otherwise, I'd prefer to at least pick 
one of the solutions that does not require a cache to track its routers 
individually.

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