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

[Ralph Covelli <[e-mail]>]

Correction:

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

Ralph Covelli
Network Engineer
Hurricane Electric / AS6939

On 12/22/2025 4:55 PM, Ralph Covelli wrote:
>
> 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]
>
> _______________________________________________
> Sidrops mailing list [e-mail]
> To unsubscribe send an email [e-mail]