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

[Ralph Covelli <[e-mail]>]

Hi Tom!

I should point out that this wording was not added by me.  I pointed out 
the hole in the logic to Randy Bush and he added the wording.

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.

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.

Weather its treated with a Cache Reset or a Terminal Error,  the 
specific wording should be added to the document.

Thanks!

On 12/22/2025 6:46 PM, Tom Harrison wrote:
> Hi Ralph,
>
> On Mon, Dec 22, 2025 at 05:00:23PM -0500, Ralph Covelli wrote:
>> On 12/22/2025 4:55 PM, Ralph Covelli wrote:
>>> On Mon, Dec 22, 2025 at 04:14:41PM -0500, Ralph Covelli wrote:
>>>> Big fan of your section 11 changes! :-)
> Thanks, much appreciated.
>
>> If you remove the wording you leave a hole behind.
>>
>> Section 5.1:
>>
>>        ... If, at any time after the protocol version has been
>>        negotiated (Section 7), either the router or the cache finds
>>        that the value of the Session ID is not the same as the
>>        other's, the party which detects the mismatch MUST immediately
>>        terminate the session with an Error Report PDU with code 0
>>        ("Corrupt Data"), and the router MUST flush all data learned
>>        from that cache.
>>
>> If the session ID changes *after* protocol negotiations something
>> has gone horribly wrong and we should error and terminate.  I agree
>> with this.
>>
>> What do we do if session ID's do not match DURING negotiations? It's
>> never stated what to do.
> My reading of the text is such that version negotiation is complete as
> at the point that the cache has received a Reset Query or Serial Query
> PDU from the router and determined that it is able to support the
> version included in that PDU, because at that point the version to be
> used for further protocol interactions has been finalised.  One
> counterargument I can see here is that section 7 includes two
> references to the cache responding with a Cache Response PDU, such
> that the sending of that response might be considered part of
> "protocol version negotiation".  However, sections 8.3 and 8.4 make it
> clear that there are scenarios in which the cache is not required to
> respond with a Cache Response PDU, so I think the better reading of
> section 7 in this respect is that the Cache Response PDU references
> are just about describing what usually happens at that point, rather
> than being an attempt to bring the cache's sending of a response PDU
> within the scope of the version negotiation process.
>
> With the above reading, the text of section 5.1 applies as at the
> point where the cache is determining how to respond to the session
> initiation PDU from the router, as well as during subsequent
> interactions between the router and the cache.
>
>> A session ID changing in the middle of a session is a bad thing and
>> shouldn't happen.  However session IDs changing BETWEEN sessions is
>> NOT a protocol violation.  It means the RTR cache restarted while
>> you were disconnected from it.
>>
>> This is a Cache Reset condition similar to falling out of the
>> sequence window, NOT a protocol violation.
> I agree that a router initiating a session with a session ID unknown
> to the cache is not that far away from a router initiating a session
> with a serial for which the cache cannot provide an incremental
> update.  However, for the reasons mentioned in my previous mail, I
> think the case for preserving the existing behaviour (at least per my
> reading) is stronger than the case for changing how this works.
>
> (FWIW, StayRTR 0.6.2 responds with an error PDU on an unknown session
> ID, while RTRTR 0.3 responds with a Cache Reset PDU.  I haven't tested
> other implementations.)
>
> -Tom
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]