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

[Ralph Covelli <[e-mail]>]

Also to simplify things on the router side you could do things like this:

Whenever you are willing to update your serial number you should also be 
willing to update your session ID number.

Its harmless in the case of the session ID not changing and it catches 
the change when an RTR cache server has restarted while you were 
disconnected from it.

Thanks!

Ralph Covelli
Network Engineer
Hurricane Electric / AS6939

On 12/22/2025 4:14 PM, Ralph Covelli wrote:
>
> Hi Tom!
>
> Big fan of your section 11 changes! :-)
>
> 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.
>
> 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.
>
> Thanks!
>
> Ralph Covelli
> Network Engineer
> Hurricane Electric / AS6939
> On 12/22/2025 12:11 AM, Tom Harrison wrote:
>> 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
>>
>> _______________________________________________
>> Sidrops mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>
> _______________________________________________
> Sidrops mailing list [e-mail]
> To unsubscribe send an email [e-mail]