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

[Tom Harrison <[e-mail]>]

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