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

[Ralph Covelli <[e-mail]>]

Woops:

*Whether* its treated with a Cache Reset or a Terminal Error, the 
specific wording should be added to the document.

Thanks!

On 12/22/2025 10:28 PM, Ralph Covelli wrote:
> Hi Tom!
>
> I should point out that this wording was not added by me.  I pointed 
> out the hole in the logic to Randy Bush and he added the wording.
>
> The problem is that the "existing behavior" is *not* clearly defined 
> in this case.  Your testing confirms this. (thank you for taking the 
> time to look)
>
> If you treat this condition as an error you will wind up unnecessarily 
> killing all of your router connections every time you reset the RTR 
> cache.
>
> In the end all roads lead to convergence:
>
> With Cache Reset:
>
> 1) Router disconnects from RTR cache
>
> 2) RTR cache server restarts
>
> 3) Router connects to RTR cache and sends Serial Query
>
> 4) RTR cache sends Cache Reset to Router
>
> 5) Router syncs
>
> With terminal Error:
>
> 1) Router disconnects from RTR cache
>
> 2) RTR cache server restarts
>
> 3) Router connects to RTR cache and sends Serial Query
>
> 4) RTR cache sends Error to Router and disconnects
>
> 5) Router connects to RTR cache and sends Reset Query
>
> 6) Router syncs
>
> The Session ID appears to be designed to detect cache changes. This 
> should work both ways.  Router to RTR cache and RTR cache to router.
>
> Weather its treated with a Cache Reset or a Terminal Error,  the 
> specific wording should be added to the document.
>
> Thanks!
>
> On 12/22/2025 6:46 PM, Tom Harrison wrote:
>> 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
>>
>> _______________________________________________
>> Sidrops mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]