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

[Tom Harrison <[e-mail]>]

On Sat, Dec 20, 2025 at 09:41:46PM -0500, Ralph Covelli wrote:
> On 12/20/2025 9:29 PM, Ralph Covelli wrote:
>> On 12/20/2025 9:05 PM, Ralph Covelli wrote:
>>> On 12/20/2025 8:54 PM, Ralph Covelli wrote:
>>>> On 12/17/2025 1:46 PM, Ralph Covelli wrote:
>>>>> On 12/17/2025 8:38 AM, Marco Marzetti wrote:
>>>>>> Dear members of the SIDROPS WG,
>>>>>> 
>>>>>> I am working on a Python implementation of a RTR Cache,
>>>>>> and I noticed some ambiguity around how session mismatch
>>>>>> should be handled.
>>>>>> 
>>>>>> At 5.1. (Fields of a PDU) the draft states that:
>>>>>>
>>>>>>    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.
>>>>>>
>>>>>> While at 5.3. (Serial Query), the it states:
>>>>>>
>>>>>>    The Session ID tells the cache what instance the router expects to
>>>>>>    ensure that the Serial Numbers are commensurate, i.e., the cache
>>>>>>    session has not been changed.  If the Session ID does not match, the
>>>>>>    cache MUST respond with a Cache Reset.
>>>>>> 
>>>>>> Does that mean that the Cache should send the Error
>>>>>> Report PDU in all cases but not in response to a Serial
>>>>>> Query?
>>>>>
>>>>> The 5.3 wording was added because of me.  Perhaps it can use
>>>>> a little more tweaking.
>>>>> 
>>>>> Both Reset Queries and Serial Queries can be the first command issued.
>>>>> 
>>>>> When the Serial Query is the *first command issued* and the
>>>>> session ID numbers do not match the RTR cache, then the RTR
>>>>> cache should send a Cache Reset.
>>>>> 
>>>>> If a later Serial Query is issued and the session ID number
>>>>> somehow changes the RTR cache must terminate the session.

I think the extra text that was added in 5.3 should instead be
removed, for a few reasons:

 - It's more consistent with RFC 8210.
 - It simplifies the implementation for both the client and the
   server, since there is no need to distinguish different session ID
   mismatch scenarios.
 - If a cache or a router sees an unexpected session ID, then some
   sort of error has occurred (e.g. cache has lost the data for a
   previously-established session).  Compare e.g. a serial query for a
   serial number that is no longer available due to the removal of
   stale data, which is not an error as such.
 - It is not clear what advantage is gained by having the cache send
   a Cache Reset when it receives an unexpected/unknown session ID.

-Tom