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

[Ralph Covelli <[e-mail]>]

Hi,

It should also be pointed out that this means when a router receives a 
Cache Reset from an RTR cache they must be willing to update their 
session ID (from the subsequent Cache Response/EOD).

When a router receives a Cache Reset because the sequence number has 
fallen out of the cache window this is not the case.

If a router continues to use the old session ID after the Cache Reset, 
the RTR cache should send an error and terminate the session.

Thanks!

On 12/20/2025 9:05 PM, Ralph Covelli wrote:
>
> Or maybe "during the protocol version negotiation" sounds a little 
> more human. :-)
>
> On 12/20/2025 8:54 PM, Ralph Covelli wrote:
>>
>> Hello SIDROps!
>>
>> Perhaps the following will clear up any possible future confusion:
>>
>> 5.3. Serial Query:
>>     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
>>     during protocol version negotiation, the cache MUST respond with a
>>     Cache Reset.
>>
>> Thanks!
>>
>> On 12/17/2025 1:46 PM, Ralph Covelli wrote:
>>>
>>> Hi,
>>>
>>> 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.
>>>
>>> Thanks!
>>>
>>> Ralph Covelli
>>> Network Engineer
>>> Hurricane Electric / AS6939
>>> 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?
>>>>
>>>> Thanks
>>>>
>>>> -- 
>>>> Marco
>>>>
>>>> _______________________________________________
>>>> 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]
>
> _______________________________________________
> Sidrops mailing list [e-mail]
> To unsubscribe send an email [e-mail]