[Sidrops] Re: draft-ietf-sidrops-8210bis-23 is ambiguous session mismatch handling

[Tom Harrison <[e-mail]>]

Hi Ralph,

On Mon, Dec 22, 2025 at 10:35:53PM -0500, Ralph Covelli wrote:
> On 12/22/2025 10:28 PM, Ralph Covelli wrote:
>> The problem is that the "existing behavior" is *not* clearly
>> defined in this case.  Your testing confirms this. (thank you for
>> taking the time to look)
>> 
>> If you treat this condition as an error you will wind up
>> unnecessarily killing all of your router connections every time you
>> reset the RTR cache.

I think these are good points.

>> In the end all roads lead to convergence:
>> 
>> With Cache Reset:
>> 
>> 1) Router disconnects from RTR cache
>> 2) RTR cache server restarts
>> 3) Router connects to RTR cache and sends Serial Query
>> 4) RTR cache sends Cache Reset to Router
>> 5) Router syncs
>> 
>> With terminal Error:
>> 
>> 1) Router disconnects from RTR cache
>> 2) RTR cache server restarts
>> 3) Router connects to RTR cache and sends Serial Query
>> 4) RTR cache sends Error to Router and disconnects
>> 5) Router connects to RTR cache and sends Reset Query
>> 6) Router syncs
>> 
>> The Session ID appears to be designed to detect cache changes. This
>> should work both ways.  Router to RTR cache and RTR cache to
>> router.
> 
> *Whether* its treated with a Cache Reset or a Terminal Error, the
> specific wording should be added to the document.

Although I think clarifying the document and providing some way to
avoid unnecessary connection terminations are useful things, I'm
mindful that there is at least one implementation that operates in
reliance on the reading I described in my previous mail.  I've had a
go at updating the text to address these problems at
https://github.com/APNIC-net/rpki-rtr-demo/commit/dd901d4f98cc3be23b798bc1e04fbd5042001965#diff-ba5205cdbf492fee8c9ee5a7c3afa6ea4f0eb87eb392a0286f9bce7eb783a631.
Do those changes look OK to you? 

-Tom