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

[Ralph Covelli <[e-mail]>]

Hi Tom!

On 1/5/2026 9:58 PM, Tom Harrison wrote:
> Hi Ralph,
> Instead of my previous suggested changes to section 5.3, what about
> the following?
>
>     If the cache does not have the data needed to update the router,
>     then it responds with a Cache Reset PDU (Section 5.9).  There are
>     two main scenarios where this will happen: when the Serial Number
>     requested in the Serial Query is no longer available to the cache,
>     and when the session ID in the Serial Query designates a session
>     that is no longer available to the cache.
>
>     Per section 5.1, if the Serial Query contains a session ID that is
>     not equal to that previously established in the session between the
>     router and the cache, the cache terminates the session with an
>     Error Report PDU with code 0 ("Corrupt Data").  The behaviour in
>     the previous paragraph is limited to the case where the router is
>     using the previously-established session ID, but that session is no
>     longer available to the cache.
>
> -Tom
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
Yes!  I think your new wording is great!  I support these changes.

Thank you Tom!

What I find so interesting about the discussion is that "what 
constitutes protocol negotiation?" is a relative question.

I believe both our positions to be valid! :-)

In this case, the RTR negotiation can be seen from 3 points of view.  
The Router's view,  the RTR Cache's view and the bird's eye view.

 From the bird's eye view and the Router's view the version negotiation 
can really be boiled down to 2 messages.  Router to Cache then Cache to 
Router.

Since the negotiation PDU can only be a Reset Query or a Serial Query 
the back and forth can follow 1 of 7 paths (I think?):

1) Reset Query -> Cache Response

2) Reset Query -> Error No data

3) Reset Query -> Error Unsupported Protocol  (fatal)

4) Serial Query -> Cache Response

5) Serial Query -> Error No Data  (maybe Cache Reset instead?)

6) Serial Query -> Cache Reset

7) Serial Query -> Error Unsupported Protocol  (fatal)

 From the RTR Cache's point of view negotiation can be thought of as 
done once the server has read the version out of the Query and decided 
what to do.  So you are *correct* from this point of view. :-)

On a side note...

I would also like to point out there are *2* cases when Cache Resets are 
used in protocol negotiation,  not just Session ID changes.

Consider the following:

1) Router disconnects from RTR cache.

2) RTR cache has history size + 1 changes to serial.

3) Router reconnects to RTR Cache and issues Serial Query on a stale 
serial number.

4) RTR Cache responds with a Cache Reset as part of protocol negotiation.

Again,  pretty much all possible roads lead to convergence anyway.

Thanks again Tom!  Awesome work!